Federated Authentication Illustrated: The story of an unwise foreign tourist

Foreword

In an attempt to illustrate how federation relationship between Office 365 and on-premise directory  works, I wanted to put together a “real-life” story that doesn’t involve any IT terminilogy. Let us follow this analogy to explain what is happening during the federated authentication process. At the end of each chapter, I will add a “translation” section that will convert this vaudeville into IT language. So here it goes:

Story of an unwise foreign tourist

Narrator: It was a dark and stormy night. The place was Moscow, Russia. The Universe was… alternative…

Decision

Narrator: In a smoky Moscow bar, one man whose name was Dmitry, has just heard of a place full of marvel. That place was Little Rock, AR. Without any hesitation, Dmitry decided to fly to distant Little Rock, to see it for himself. Little did he know that he was about to embark on a worldwide journey.

Translation

User typed  http://portal.microsoftonline.com in his/her browser (alternativly to skip next chapter user could have typed http://outlook.com/contoso.com to perform realm-discovery and avoid typing user-name twice)

Knocking at the door

– Knock Knock…

– Who’s there?

It’s Dmitry; he has arrived to the Little Rock airport. To no surprise to us, and to his complete amazement, The Port Authority of Little Rock has told him that he needs to authenticate himself. Being part of the United States, Arkansas does not issue its own passports or visas, instead they would recognize only one form of authentication, from the United States Immigration Services… commonly  known as a visa. Port Authority folks were polite about it (mind you, we ARE in an alternative universe here) and they gave Dmitry the address and directions to the centralized US Border Control office. They also told him to return to Little Rock when his papers are in order.

Translation

Since outlook.com is only accepting authentication from the Office 365 authority, outlook.com has redirected our user to the Office 365 login page, as it could not authenticate him/her.

Foreign Authority

Narrator: We should note that most foreign countries in our alternative universe have their difficulties with trusting each other. Borders are guarded vigorously. Bureaucracy is erected to protect them. Russia and The United States, in this case, are not an exception. However, both do recognize the fact that their citizens do need to visit the bordering country from time to time. Therefore, they have signed an agreement. That agreement defined that Russian citizens can use Russian-issued passports to identify themselves at the US Border Control office. Each issued passport shall have a unique citizen identifier, and a unique citizen name. The US Border Control shall send all Russian citizens without passports back to the predefined address in Russia.

Dmitry: I am Dmitry from Russia. Here is the paper from Little Rock folks telling me to come here.

US Border Control: Your Russian passport, please.

Dmitry: I don’t have one

US Border Control: According to our agreement with Russia, you must fly back and ask for your passport there. Here is the address in Russia you must visit. Return when you have your passport. Good-bye.

Translation

By virtue of the user typing his/her login (RegEx looking at the “right side” from the @ sign of user name OR looking at the URL header such as outlook.com/<%FederatedNamespace%>) Office 365 discovered that the requestor is from a federated namespace, and therefore Office 365 doesn’t have the user’s credentials. It must redirect the user’s browser to a known/predefined on-premise Security Token Service end-point, which will authenticate the user and issue a predefined ticket containing an immutable ID (the unique citizen identifier in the story) and UPN (unique name in the story).

I am who I am! Aren’t I?

Narrator: Dmitry’s flew back to Russia and arrived at the local passport agency office as directed by the US Border control.

Dmitry: I have been sent by the US Border Control office, telling me that I need a passport. Can I have one, please?

Russian Passport Agency: That’s great! Who are you, exactly?

Dmitry: I am Dmitry. Here is my birth certificate. It plainly says that I am Dmitry.

Russian Passport Agency: We have verified your claim with our back-end registry. You are who you say you are. Here’s your passport, we have stamped your federal ID number and your unique name into it. Go back to the US.

Translation:

The user has landed on the on-premises federation-server user-authentication page (The “Russian Passport Agency” in this story) and has entered his credentials. NOTE: The ADFS will accept the user’s sAMAccountName (the birth certificate in this story) and the password combination OR user’s UPN and the password combination. Once the user is authenticated, ADFS issues a token containing the user’s UPN and unique identifier (default unique identifier is AD GUID in base64 encoded string). It is important to stress and understand that UPN value is not required by the ADFS’s login-page/dialog box to actually authenticate the on-prem user, however it is required to be enclosed into the issued claim that is sent back to a requesting federated party (Office 365 in this case). Once again, the user can actually authenticate with sAMAccountName, yet his/her UPN value will be sent back to Office 365 instead of sAMAccountName as defined during ADFS configuration.

Take Two

Narrator: Armed with a newly minted Russian passport, Dmitry arrives at the US Border Control (again).

Dmitry: I am Dmitry from Russia. Here is the paper from the Little Rock folks telling me to come here for a visa

US Border Control: Your Russian passport, please

Dmitry: Here it is, shiny and new.

US Border Control: Your documents are good. Welcome. Here’s your visa. Now you can fly to Little Rock

Translation:

Now that user’s browser contains a valid token, the user can be authorized to access Office 365 resources, and therefore redirected yet again to his/her destination with a resource token consumable by Office 365 resources, such as Exchange Online, Lync and SharePoint/SkyDrive Pro.

Final Approach:

Narrator: Armed with his US visa, Dmitry arrives back in Little Rock.

Dmitry: I demand to see Little Rock

Port Authority of Little Rock: Do you have a visa?

Dmitry: Here’s the US Border Control issued visa.

Port of Authority: Excellent! Welcome!

Translation

By having a resource token, the user can access target federated resource; in our case it is Exchange Online mailbox.

Epilog:

Although Dmitry’s journey was not straightforward, he arrived at his final destination with the help of a well-defined sequence described by protocols and agreements. If only he would have been smarter, and knew the process he had to follow, he might have saved some time for himself, but that is another chapter for a later time.

Translation:

The described “choreography” pertains only to the “Passive Requestor Profile” that is primarily used by web-browsers. Rich clients such as Outlook, and clients such as mobile devices, employing ActiveSync, are using other types of profiles (active requestor profile); while Lync is using Metadata Exchange (MEX) protocol. Both of these methods are a little “smarter” than the passive requestor profile sequence and therefore allow for a richer user experience and consequently more features.

2013

03/14

CATEGORY

Federation
Office 365

Write comment