In this video I have recorded for #collab365, I discuss the different integration possibilities between Yammer and other systems, out of a real-world project.
With just over 3 weeks to go to Europe's largest gathering of SharePoint & Office 365 professionals, take a look at these tips that will help you get the most out of ESPC16…
Find out who’s going
Check out Twitter #espc16 to find out who’s going. There’s no better time to network with your peers, connect with new prospects, or touch base with customers than ESPC16. Don’t bank on running into them at the conference, reach out to them before and arrange a meeting.
The present paper discusses the historical technical issues and limitations of the Web's successive technological paradigms. The main research question is whether the latest one, HTML5, appropriately remedies these identified shortcomings. The methodology is based on concrete examples, and on two case studies targeting the major contributions of HTML5, namely: the WebSockets and the Web Workers.
When creating Azure AD Proxy Applications to expose on-prem WebAPIs, you have to do a few things such as:
- Installing the proxy connector on an on-prem server (that has access to the web api)
- Configuring KCD in order to let the service account and/or the computer create Kerberos tickets to consume the on-prem API
- Configure your on-prem API's IIS to work with Windows Integrated security
- Enabling some Windows Server Features
- Creating an Azure AD App of type "proxy" to bridge the Cloud and your on-prem API
You might have noticed but in the recently added Azure AD section of the Azure Portal (portal.azure.com), the App creation experience seems to have changed compared to doing the same operation from the old portal. From the old portal, when one create an app of type Web as a global admin, the following sequence occurs:
- The app is created
- A service principal is created
- an oauth2PermissionGrant is created
Although the Microsoft documentation on this topic is already quite good, I think that it might sound a bit rude to people who aren't familiar with Azure AD Authentication and Office 365 APIs in general, especially because that API is probably one of the most complex ones.
Therefore, I decided to write this short walkthrough on how to capture some SharePoint Online events such as who shared a document with external users and get notified about that and possibly intervene.
As you might have noticed, if your company has a 365 environment, you're unlikely having an SSO with it. Most of the times, when you enter the URL of your SharePoint Online landing page, say : https://contoso.sharepoint.com/, you are prompted to enter your e-mail address. If you use the same e-mail address for a Microsoft Account and an Organizational Account, you'll get a second prompt invite to choose the type of account you want to sign in with.
I've recently been involved in a project whose the purpose was to extend the Corporate Intranet with the Video Portal of Office 365. While the 365 UI sounds the natural location to upload/edit videos, it might not be the default location to list them. In the context of a Corporate Intranet home page, one might want to list the available videos and their thumbnails, and let the users decide whether or not they want to watch a given video.
In that case, you have two different options to download the metadata of the videos into your home page :
I've recently been involved in a project whose the purpose was to extend the Corporate Intranet with the social capabilities of Yammer. No matter what you do, you have different options when it comes to integrate with Yammer. Here is a list of options with pros & cons of each:
1) Yammer Client SDK
As you might know, Azure Key Vault is a set of repositories one can use to store key/value pairs of secrets, certificates etc. in order to facilitate the maintenance of this information. Key Vault comes with "Keys" and "Secrets" but I'm only going to focus on the "Secrets" part. Storing secrets is an easy game as you can achieve this using the Azure Key Vault Cmdlets (https://msdn.microsoft.com/en-us/library/dn868052.aspx) that allow you to interact with the Vault. But once you've stored all the secrets, you need to make them available to applications. Vault makes this possible by granting the SPN corresponding to the Azure AD App, access to the Vault via the Set-AzureRmKeyVaultAccessPolicy cmdlet.
So far so good but which approach should we adopt? There are several possibilities among which, granting access to Key Vault directly to the business Azure Active Directory App. While this approach works, it is not the most effective for the following reasons:
- Granting access directly to the business App will end-up in a chaos once you’ll have a lot of different apps. You’ll also need to grant each of this apps individual access to the Vault which will make the maintenance tedious.
- At Azure AD App level, one can create secrets and associate permissions to the App but you can’t restrict a given secret to a specific set of permissions. In order to access Key Vault, you must create a secret so that the App can use the ClientCredential flow, but since the secret you create isn’t restricted specifically to Key Vault, it also allows developers to access other resources, and therefore, they could as well bypass Key Vault to consume theses resources, and that’s not really what you intended.