I'm not a fan of ADFS. It sits right below Azure Access Control Services (ACS). ACS used to be my favorite identity provider aggregation platform, but how times change (ref this post). Several new players are entering the market and all of them realize the missing gaps in ADFS and ACS. Therefore, the drive to make a better authentication toaster is ON!
The goal of this post is to make you realize that you are having the wool pulled over your eyes in terms of the bigger picture around Identity Management when it comes to O365. To make this point, let's take a look at a typical on-premises solution:
- A SharePoint customer wants to setup multiple site collections (yes, all host header site collections) to support different customers
- Each customer has different requirements around supporting federated external customers
- Some customers prefer Google as their auth, others Yahoo and others Facebook, etc
On-premises
Solving this problem with on-premises environments is a piece of cake. You have complete control over adding trusted Identity Providers (IdP) all day long. To solve the problem above, its likely you are going to think that adding a Trusted Identity Provider for each required auth mechanism is the answer. That would be false. As tempted as you may be to do this, its a really bad idea to have more than one. You should ultimately have a single Identity Provider with that provider supporting multiple "Apps/Replaying Parties (in this case site collections)" that would then show different options when a user needs to auth. This allows you the most flexibility in that you simply set the IdP once, then configure the apps in the IdP. Totally seamless, perfect.
Office 365 and Single Sign On (ADFS)
If you had this requirement in O365, you are out of luck. Do not pass GO, do not collect $200USD. In terms of O365, you are by default forced to use this one IdP mentality. For each verified O365 domain, you can only setup a single Federated Identity Provider. In most cases, everyone I have seen has used ADFS to integrate their on-premises Active Directory to sync accounts and/or configure Single-Sign On to redirect to their ADFS proxy. This unfortunately, is the Microsoft promoted way of achieving Single-Sign-On nirvana. I'm not a baby swimming in a pool, so let's take a look at what lives outside the koolaid-y-ish sugar water. If you do this (which unfortunately, you probably already have), you are locking yourself into the current limited features of ADFS and hoping that ADFS gets some much needed development attention in the future (such as supporting OAuth 2.0). That being true, ADFS is a Microsoft product, you'll find a lot of people that can help you (support and consultant resources) to get it setup within a few hours. You could also do it yourself by using TechNet/MSDN et all.
Office 365 and Something else
If you want to use something other than ADFS, well, you better dig in for doing a ton of research on how WS-Fed and WS-Trust works and similarly, OAuth. If you don't have time for that, then you'll need to request the services of people that do know that space. Unfortunately, having the identity management skills matched with an understanding of the future of App Models across vendors is a rare breed of consultant. You also have to contend with a cold hard fact:
- Currently, Office 365 only supports users of your verified domains (such as contoso.com)
Say what? It means that even if you wanted to use Twitter, Facebook, whatever, the people that signed up have to have used the email address from their verified domain! Uh…say that again? Yeah, that means you can't login with your user@hotmail.com account using Facebook. If you signed up with your contoso.com account on Facebook, then it will likely map your email over in the claims and let you in, but that's up to how fancy your Identity Provider is. Azure AD is expecting a very specific format of token with specific claims. If it doesn't get them, then your login will fail.
So if you can't login using something other than a verified account, what's the point?
I feel this is a major fundamental loss of functionality between on-premises and O365. If I want to create a site collection with a specific relaying party app to my IP (which then provides a set of auth services), I should be able to do it. It is such a common pattern in on-premises SharePoint. I don't think the band aid of "external access" fits the bill here. Those links that are generated can be freely sent all over the web punching small barely noticeable holes in your O365 tenant. I'd like to see the governance page in O365 that shows me every link that has been generated across the entire tenant (you can see on a site by site basis using this link – https://domain.sharepoint.com/_layouts/15/start.aspx#/Access%20Requests/pendingreq.aspx). There is not global admin UI to tell you who has been added or what has been shared – reference notes at bottom of this article. With an IdP in the picture, you simply disable their access and now they will never gain access to anything in your environment. This would require the removal of this "external sharing" feature that bypasses Azure AD in O356. Wow, isn't that innovative?
Can I even use something other than ADFS in O365?
Heck yeah you can! I recommend it! By adoptingchoosing an Identity Provider solution (whether one you install on-premises or cloud hosted) that allows for you to expand
out past basic AD accounts, you will be ready for when Azure and O365 wakes up one day to
realize they should have allowed it in the first place. You can set this up by removing the ADFS federation and replacing it with new Ws-Fed endpoints of your IdP. This is enabled using the following cmdlets (this one is using Auth0.com):
- $cred = Get-Credential
- Connect-MsolService –Credential $cred
- Set-MsolDomainAuthentication -DomainName "chrisgivens.com" -FederationBrandName "chrisgivens.com" -Authentication Federated -PassiveLogOnUri "https://chrisgivens.auth0.com/wsfed/ID" -ActiveLogonUri "https://chrisgivens.auth0.com/ID/trust/usernamemixed?connection=yoyo.chrisgivens.com" -MetadataExchangeUri "https://chrisgivens.auth0.com/wsfed/ID/FederationMetadata/2007-06/FederationMetadata.xml?connection=fs.chrisgivens.com" -SigningCertificate "Cert" -IssuerUri "urn:chrisgivens" -LogOffUri "https://chrisgivens.auth0.com/logout" -PreferredAuthenticationProtocol WsFed
NOTE: If you have already setup ADFS, you'll need to disconnect from that. I have yet to test out all the paths, but the one I choose was really painful. I used the Remove-MsolFederatedDomain cmdlet. This forced me to remove all users (but did not require me to remove my groups). Once I removed all users the command succeeded, but proceeded to delete the domain completely from my tenant! I then had to re-add it, re-verify it, then fire off a DirSync. Once that once done, I could run the above commands and it redirected properly to my IdP.
After configuring the federation when you go to "login.microsoftonline.com" and type your verified email, it will redirect to your IdP login page. From there, you will see all the options that you have enabled for that relaying party. Even though you can enable all the OAuth 2.0 providers you can imagine, an attempt to login will fail miserably. There are some current technology issues that Azure AD must resolve:
- Azure expects a UPN/Email that matches a user in your Azure AD (at a minimum, you would have needed to sign up for a service using that verified domain email)
- Azure AD is expecting an ObjectID
- O365 Services have to support these accounts (even if that means simply ignoring them)
For the first issue. Azure AD would have to allow the addition of users other than your verified domain. Or at your IP, you map a user from external to internal. For the second issue, again, this can resolved by either Azure, or by the Identity Provider. IPs can choose to implement this today by integrated with Azure AD to query for the object id based on a valid UPN.
Until this these items are resolved, you can certainly fall back to the "forced" way by Microsoft to use Active Directory users from a verified domain (and yes, you should feel angry about this) by setting up a pass through from your IP to ADFS/Active Directory. The preferred way is to utilize a client on your Active Directory server (pretty much every IdP has this). As only a few of you know or will understand, if you use ADFS, you will currently lose Office Client features. But don't be worried, later this year, Office will release an update that will support SAML-P. This will let you utilize many different types of auth (basically anything you can do via browser) with Office clients. That will be awesome, even though users will never fully understand what just happened.
Take It Up Another Level
Home realm discovery is not extensible in Azure AD. What is home realm discovery? Its the login drop page that takes your context, in this case, your email domain, and then redirects you to the proper IdP. What does it mean to not be extensible? It means that IdP's cannot create a portal of Apps page. What does that mean? Think Universal Access Gateway (UAG). Imagine UAG-like portals, only hosted by your IdP, such that an external party can login to your IdP, and are then presented with the applications (such as O365), that they have access too. When they select it, it will immediately redirect you to your O365 site (no need to go to login.microsoftonline.com). As it stands right now, O365 does not support external home realm discovery pages. This is also a serious limitation that needs to be added to the road map.
Summary
If enough people push the O365 and the Azure teams to fill the gap of this major difference between the products, I feel it would fulfill many of the requirements we have with customers today and make O365 an even more popular platform! Here is your call to action:
- Quit using ADFS, find an IdP with an eye towards the future
- Highly "Suggest" to Azure and O365 that they support external identities (Vote for it here on UserVoice)
- "Suggest" to Azure that they allow tenants to have a custom home realm discovery page
Stay classy internet,
CJG