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.
Case Study : opportunity to leverage Spotlight & Alchemy’s NLP capabilities within an open source SharePoint auto-tagger
This blog post deviates a bit from my usual topics but as I recently had to make an analysis in the context of a master degree I'm attending at night, I thought it might be an interesting reading for some folks, so I'm publishing the paper I wrote for a particular course.
If you happen to encounter any security exception with keyvault, make sure you pay attention to how you grant access to the Azure Active Directory Application. To grant access to the application, make sure you grant it to the corresponding service principal and not to the app itself.
One of my team mate went through the application endpoint of the Graph Explorer this way:
As I am more and more using Azure Active Directory Applications to consume online services such as SharePoint Online, Yammer etc., I found myself annoyed with the duration of the client secrets.
As you know, when creating an app from the UI, you can set permissions and create a secret key with the GUI:
but it only lets you chose either 1 year either 2 years with a startdate being the creation date.
I don't know if you've ever played with Azure Active Directory Application permissions to consume SharePoint Online but you should know that the major advantage they offer compared to Add-Ins is that you can grant Azure Applications access to SharePoint in a transparent way for end users since you don't need to install anything in SharePoint.
I have developed a NuGet package that helps exporting data from Yammer. It's a simple .NET wrapper that consumes the Yammer export API. It allows you to retrieve either :
- Files (metadata only or metadata+binaries)
- Inbound Threads, meaning external messages in which internal users take part
- Outbound Threads, meaning internal messages in which external users take part