How Does ADFS Work With Office 365?


You might know something about Microsoft Active Directory Federation Service (AD FS) or maybe not, but basically it’s a Microsoft feature that enables SSO (Single Sign-On) between two domains/forest without using a normal domain trust relationship as many people might know it.

ADFS is NOT a trust between two domains, instead it uses a claims-based model, where claims are issued in SAML tokens and processed based on different rule sets by the claim engine which have three primary tasks:

  1. Accepting incoming claims roles (acceptance rules)
  2. Authorizing claims requesters (authorization rules)
  3. Issuing outgoing claims (issuance rules)

Besides the claim engine which process the claim rules, ADFS have three main relationships to control this entire function.
These three relationships are:

  • Attribute Store
    This is where ADFS get’s the users and there attributes from, this is normally Active Directory but ADFS also supports LDAP an SQL
  • Claim Provider Trust
    This is where the trust between the ADFS server and the claim provider is configured. Based on a set of rules called the “Acceptance Transforme Rules” the claims from the claim provider will be filtered or pass though to the “Relaying Party Trust”. You can say that In Office 365 the claim provider is the “Authentication platform”.
  • Relying Party Trust
    This is where the trust between the ADFS server and the relaying party is configured. Here the ADFS controls which users have access to the relying party based on the “Issuance Authorization Rules” and then it issues claims to the relaying party based on “Issuance Tranform Rules”. You can say that in Office 365 the relying party is the Exchange Online, SharePoint Online etc. But in reallity it’s properly more the “Authentication Platform“.

All this might be a little hard to understand so I recommend reading the documentation Microsoft provides on understanding key concepts of ADFS, which can be found here

Here is how Microsoft has drawn the Claim pipeline:

Claims_pipeline

 

But don’t be afraid, Microsoft has a nice and easy guide how you setup this for Office 365 and your domain. This guide can be found on the Ofiice 365 portal under Management-> Users -> Next to Single sign-on click “Set up”

Ross Adams – Senior Program Manager at Microsoft had a very good presentation at TechEd 2011of how ADFS works against Office 365. You can see the whole presentation here: Microsoft Office 365: Identity and Access Solutions.

I have done a little video and PowerPoint editing and will try to explain the three ways ADFS will work with Office 365 as Ross Adam also explains in his TechEd session.

First scenario is where a user is trying to access one of the web based apps from it’s domain joined client:

This movie requires Flash Player 9

What happens in the flash animation above is the following:

  1. The users hits the web based app.
  2. The web based app says that you need to authenticate and it returns URL to the Authentication Platform
  3. The Authentication Platform then takes the domain/UPN the users typed in and knows if it a federated domain/UPN, so it returns another URL to the client that points to the ADFS server.
  4. The ADFS server will ask the user to authenticate via Kerberos or NTLM and when the user is authenticated, the ADFS server gives the user an SAML token including the claims: UPN and Source User ID (ImmutableID).
  5. The client embeds this token in the old URL and sends it of to the Authentication Platform
  6. The .Authentication Platform verifies the token and converts it to an Auth token, which contain the UPN and now Unique ID from the Authentication Platform. This Auth. token can now be used for login
  7. So it gets back to the client and then off to the web app.

 

Second scenario is where the sign in assistant is used for accessing Lync Online from a domain joined client:

This movie requires Flash Player 9

What happens in the flash animation above is the following:

  1. First the user login to there machine/client
  2. After they login the sign in assistant kicks in
  3. The sign in assistant already know the UPN etc. of the user and goes directly to the Authentication Platform
  4. The Authentication Platform return the URL to the sign in assistant pointing to the ADFS server .
  5. The sign in assistant then goes to the ADFS server and authenticate via Kerberos or NTLM and when the it’s authenticated, the ADFS server gives the user an SAML token including the claims: UPN and Source User ID (ImmutableID).
  6. The sign in assistant take the token to the Authentication Platform
  7. The Authentication Platform verifies the token and converts it to an Auth token, which contain the UPN and now Unique ID from the Authentication Platform. This Auth. token can now be used for login.Note all above happens at logon and the users doesn’t see it.
  8. Now the user starts Lync
  9. Lync connects to Lync Online
  10. Lync Online request a Auth. Token
  11. The client have one of those and sends it to Lync Online.

Third scenario is the same as above (Lync onlin) but now with Outlook/Active Sync

This movie requires Flash Player 9

What happens in the flash animation above is the following:

  1. The user login and the sign in assistant kick in as above and do the round-trip to get the Auth. token.
  2. Now the user starts Outlook
  3. Outlook connect to Exchange Online and it will request Basic authentication
  4. The user will get at prompt and here they need to type in there username with an UPN ex. adam@domain.dk they can save this, but they will get prompted the first time.
  5. This will be send off to Exchange Online
  6. Now Exchange Online does a trick called “Proxy Auth” where it creates a shadow representation of the user.
  7. It then take the domain/UPN from the basic authentication and sends it to the Authentication Platform.
  8. The Authentication Platform returns with the URL to the ADFS server.
  9. Exchange Online then takes the basic authentication credential and sends them to the ADFS server.
  10. The ADFS server authenticate with the basic credentials and converts them to a SAML token including the claims: UPN and Source User ID (ImmutableID).
  11. This comes back to Exchange Online
  12. Exchange Online sends it to the Authentication Platform
  13. The Authentication Platform verifies the token and converts it to an Auth token, which contain the UPN and now Unique ID from the Authentication Platform. This Auth. token can now be used for login.
  14. Exchange Online can now authenticate the user and it will delete the shadow representation of the user.

, , , ,

  1. No comments yet.

You must be logged in to post a comment.