Office 365 Supports SAML 2


Today while I was prepping for a training I'll be delivering on Office 365, I came across a _very _interesting discovery: Office 365 supports SAML 2! I get a lot of emails about this, so I wanted to explain real quick.

The training course is about how to set up Web SSO to Office 365 using a federation server other than ADFS, namely PingFederate from our partner Ping Identity. When I worked out how to do this a year and half ago, I explained at CIS how it required WS-Federation. While prepping my slides today though, I saw something that tipped me off to the possibility of doing it using SAML 2. While looking around for the reference docs for the MSOL PowerShell commands, I found this page explaining how to setup SSO to Office 365 using Shibboleth. From this, I figured that Shib supported WS-Fed, which surprised me a bit. Curious, I looked at the following snippet which is shown on that page for establishing the trust between Shibboleth and Microsoft Azure Active Directory:

$dom = ""
$url = "
$ecpUrl = ""
$uri = ""
$logouturl = ""
$cert = "MIIFYzCCBEugAw...2tLRtyN"

Set-MsolDomainAuthentication -FederationBrandName $dom -Authentication Federated
  -PassiveLogOnUri $url -SigningCertificate $cert -IssuerUri $uri -ActiveLogOnUri
  $ecpUrl -LogOffUri $logouturl -PreferredAuthenticationProtocol SAMLP

I saw the URL, and thought it was weird that Shib would run WS-Fed messages through an endpoint w/ SAML 2 in the name. Then, I saw that parameter PreferredAuthenticationProtocol and it's value SAMLP. (SAMLP is what Microsoft calls SAML 2 to differentiate it from the SAML 2 assertions that are passed in WS-Federation and WS-Trust messages.) I started to get really intrigued, and ran the Set-MsolDomainAuthentication command w/ a -? to see if this interesting parameter was accepted. Nothing. Then, I upgraded my version the Microsoft Online module for Windows PowerShell, and reran the command. To my surprise there was still no PreferredAuthenticationProtocol parameter listed. No stranger to Reflector (especially when it comes to getting interop like this working), I inspected the implementation of the PowerShell cmdlets. There it was!

SAML federation protcol

See that? It supports WS-Federation _and _SAML. After a bit more digging, it was clear that the Confirm-MsolDomain cmdlet accepts this hidden parameter as well. So, setting up a federation connection with any SAML 2 federation server and Office 365 is as easy as running the 4 commands and creating some DNS records:

  1. Connect-MsolService
  2. New-MsolDomain
  3. Get-MsolDomainVerificationDns
  4. Create the DNS records to verify ownership (w/ PowerShell if you're a MS scripting haxor like my friend Edwin!)
  5. Confirm-MsolDomain w/ our newly discovered secret PreferredAuthenticationProtocol parameter

I don't have time to go into more detail because I've got to finish the training preso, but leave a comment below or drop us a line if you have questions.