Skip to content

Access O365 On Demand, Part 1

Recently one of my customers posed the following problem.

They have O365 SharePoint Online and they need to provide access to this site to many of their external customers.

They want to ensure high level of assurance of those users and it requires some type of multi factor authentication. One of their requirements is that external users should be able to access to their O365 SharePoint site on demand, without a long verification process for account creation.

The customers would come from a known set of e-mail domains or from a set of the trusted Identity Providers.

With O365 there is really no build in process to automate any of it so right now they have to create accounts in O365 for each of the new users by hand and provide full account management to these users, such as password management.

They are not happy about all of this overhead for multiple reasons:

  1. Account creation for external users takes too long. They have to verify the identity of the user via some type of out of bound process.
  2. They don’t want to get into business of managing passwords and other account management issues.
  3. They would have to pay premium for multifactor authentication with O365 for all those external users.

So they posed a question – is there any type of solution that would allow some type of automated account creation in O365 for external users, as long as they are coming from trusted known Identity Provider or they belong to organization with trusted known e-mail domain name?

While the requirements might sound not very complicated, in reality it is actually fairly hard problem to solve. I started thinking about possible solutions to this problem, trying to figure out if some of other integration solutions would allow us to provide a solution to this customer.

To satisfy the first requirement we’d have to come up with self registration solution. This is actually have been done and we can create accounts for external users based on their e-mail domain or register them if they are coming from trusted Identity Provider.

The second problem can be addressed by implementing SSPR solution with the account creation system or it can be fully outsourced to the trusted Identity Provider who manages accounts for those users.

The third problem can be addressed if the trusted Identity Provider can assure that they use some type of multifactor authentication.

And of course on top of all of this we have to figure out all the technical details and see if any of the possible solutions will actually work with O365.

Stay tuned for the next installment. I’ll share some details on how it can be done and some limitations.

Advertisements

Deploying AD DS in Azure IaaS

If you want to see and learn how to deploy new AD DS Forest into Azure IaaS then check out my new video demonstration. Make sure to watch it in HD.

Deploying AD DS in Azure IaaS from Dmitrii on Vimeo.

WAAD AS IdP

In my prior two posts I demonstrated how WAAD can be configured as IdP. In this post we document this on paper. The configuration is very simple, but so far I could not find it documented anywhere, so here it is for anyone interested.

In first scenario we will configure WAAD as IdP for Azure ACS. Like shown on this diagram:

image

To configure ACS as relying party in WAAD you need to do the following:

  1. Add new application in your WAAD tenant
  2. Name it whatever you like it
  3. For App URL:, put the following URL https://<your-acs-name>.accesscontrol.windows.net/ , where <your-acs-name> is the name of the ACS you created in your Azure subscription.
  4. For App ID URI:, put the same URL as in previous step.
  5. Save configuration.

Of course you’ll need to add WAAD in ACS as IdP as well.

In second scenario we will configure WAAD as IdP for AD FS. Like shown on this diagram:

image

To configure AD FS as relying party in WAAD you need to do the following:

  1. Add new application in your WAAD tenant
  2. Name it whatever you like it
  3. For App URL:, put the following URL https://<your-sts-dns-name>/adfs/ls/ , where <your-sts-dns-name> is the URL for your AD FS server (for example sts.cloudidentityblog.com)
  4. For App ID URI:, put the following http://<your-sts-dns-name>/adfs/services/trust, where <your-sts-dns-name> is the URL for your AD FS server (for example sts.cloudidentityblog.com).
  5. Save configuration.

Of course you’ll need to add WAAD in AD FS as IdP as well.

There is no mechanism to configure WAAD as to what type of claims it will provide to RP. It is hard coded to provide half a dozen claims for the user. If you need to get information about the user that is not passed via claims you’ll have to use Graph API to query WAAD and find that information programmatically (your app will have to do this).

Azure AD as IdP via ACS and AD FS

So I’m somewhat on the roll here and last night recorded another quick thirty minutes demonstration for you guys. This one is very similar to the last one,  we are still using Azure AD as an Identity Provider, but this time we putting Access Control Service between AAD and ADFS/ application. Just like on this diagram.

image

So if you want to see how it works and more importantly how it can be configured then check out my latest video. Make sure to watch it in full screen and HD. Have fun and let me know if you have any questions.

Thanks, Dmitrii Lezine.

Azure AD as IdP with ACS and AD FS from Dmitrii on Vimeo.

Why use AAD as IdP via AD FS RP

In my previous post I showed to you how easy it is to configure Azure AD to act as Identity Provider to Relying Party applications via AD FS. There were questions about ability to configure applications directly with AAD. If it is possible and if it is, then why would anyone want to use AD FS in the middle. The answer is yes, of course it is possible to configure applications to work directly with AAD, in fact most of the AAD online documentation provides examples on how to do that. The second part of this, ok, since we can configure apps to work directly with AAD, why put AD FS in the middle? The simple fact is that not all applications will be configured directly with AAD, and there are a lot of applications that are already configured in some type of federated topology. Lets take a look at the following diagram, here we have hub/spoke environment with a few Identity Providers, central hub and a few applications. Users at each IdP are able to use applications via the central hub. The fact of the matter here is that those IdPs can be any compatible Security Token Service and those IdPs do not care how other IdP are configured. As long as IdP-HUB RP relationship is working, users will be able to access target applications.

image

This design accommodates requirement to add any number of new Identity Providers and get them to access target applications. So if we have a new customer who uses AAD as their primary user directory and they need to get access to some existing apps, the primary solution would be to configure AAD as another IdP against our hub RP AD FS. Now users in AAD will be able to gain access to the applications. Hub RP claim rules can even transform incoming assertions from one claim type to another, to whatever is required by the  target application.

image

Thanks for stopping by!

Azure AD as IdP with AD FS as RP

A few weeks ago I mentioned that I’d like to do a series of posts about different topologies and capabilities with claims based authentication. Well, I decided to start with one of the last from the list and show how we can use Azure Active Directory (AAD) as Identity Provider with AD FS being a Relying Party.

This demonstration shows the following topology:

image

User gains access to the claims enabled application with his identity coming from the Azure Active Directory. For better viewing experience make sure HD is ON and view it in full screen.

Azure Active Directory as IdP and AD FS as RP from Dmitrii on Vimeo.

Comments? Leave it below.

AD FS in Server 2012 R2

TechEd 2013 is happening right now and they are talking about upcoming exciting  features in the upcoming Windows Server 2012 R2.

There are many new features will be introduced in the next Server release. I’m still trying to digest all the new functionality. You can take a look at already delivered presentation about Access and Information Protection, check is out here:

http://channel9.msdn.com/Events/TechEd/NorthAmerica/2013/WCA-B207