1
votes

iam currently researching how to implement Single Sign On for our WebService. This is what i came up with so far.

  1. If a customer of our WebService has an AzureActiveDirectory they can log on with their active directory user account to our WebService if we provide the nessecary interfaces for SAML, Oauth2, OpenID or whatever authorization protocoll we chose and azure supports.
  2. The customers could also have their local network Active Directory synced to their Azure AD and use their Domain accounts to log on to our WebApplication.
  3. Customers need to use the myapps.microsoft.com portal to "wrap" authentication.
  4. Once everything is set up correctly the Identity Provider (AzureAD) would provide use with (e.g) an authenticated User Identity.

Here is were my problem begins. Of course i need to somehow map the identity provided by the AzureAD to a certain Account for our WebService - we cannot simply use the provided identity.

As far as i understand it, you can grant AzureAD the right to create an Account on the target WebService in the name of the user which is currently signing in. (Its called : enabling automatic user provisioning in the azure management portal).

However, when testing this with the Box, Canvas or Google apps i failed. Either i got an error or in the case of google apps i was just promted to login with my azure AD test account and then asked for a password and username of my google account (i set up SSO as an azure AD trust relation- so this should not happen)

Can someone provide some insights on how to accomplish the following?

Once the user is authenticated by SSO I want to create an account for our WebSerivce and then save the credentials for that user only in the Active directory of that particular user. So if the user logs in the second time we can check wether there is an account already existing and log in the user with this account.

(I was told by microsoft that this might be possible with Azure Rights Management, but i cannot really find good documentation on that)

Storing the relationship: "Microsoft AD Identity <-> our WebServiceAccount Credentials" on our side is not desired because we cannot securly encrypt the data in a way that we DONT know whats in there. (or there is , and i dont know of it yet)

"Bonus Question": Can i support SSO for a desktop application too? (Do i need a provide proxy web application or can the desktop app do this directly?)

2

2 Answers

2
votes

Please see my answer to a similar question here: asp.net azure active directory user profile data

However - I'm trying to understand if you need something different. Are you expecting your customers to already have a directory and Azure AD accounts (maybe through having Office 365 subscriptions), and use those to sign in to your web app, or does your app scenario require creation/provisioning of user accounts into your customer's Azure AD directory? Provisioning can be done through graph API (as per your link), as long as the admin of your customer grants consent to allow your app to write to their directory. You can find some samples on github, and I recommend you look through https://msdn.microsoft.com/en-us/library/azure/dn499820.aspx and https://msdn.microsoft.com/en-us/library/azure/dn646737.aspx for code samples.

HTHs,

1
votes

I think, without testing it. That using the Graph API enables me to save custom data for any Directory User effectively enabling my desired functionality. This is the documentation i found very usefull.

https://msdn.microsoft.com/en-us/library/hh974476.aspx