If you’ve played with Azure AD at all, one thing you may have noticed is that there is this concept of “Azure AD Integrated Applications”. You can create an “Integrated Application” in Azure AD and the application gets its own object representation in the directory. You can then manage the various settings related to how the application interacts with Azure AD, such as configuring federated authentication or directory access. In this post, I’m going to take a look at Azure AD endpoints that are related to Web Sign-In, with Azure AD acting as an IdentityProvider for an application.
One misconception that some folks may have is that Azure AD is a cloud identity service that can only be used for Azure applications. This is far from the truth. In fact, you can federate both custom and commercial on-premises applications with Azure AD, as well as applications from well-known Internet Service Providers. In doing so, your Azure AD tenant acts as the Identity Provider STS for the application by providing a couple of different endpoints that the application can use (Note: The OAuth and Graph endpoints in Azure AD are not used for Web Sign-In, so I won’t be covering them in this post):
Your user principals could be synchronized from your on-premises directory to Azure AD via DirSync, or they could exist solely in Azure AD. Either way, when Azure AD is your identity provider, your application requests a token from one of the Azure AD Web Sign-In endpoints and your users authenticate with Azure AD directly. There are a number of endpoints available for your on-premises applications to use, including the WS-Federation and SAML-P endpoints to use for web sign in. Here is a screen shot of the endpoints available in one my current Azure AD tenants.
As I mentioned earlier, I’m going to ignore the Graph API and OAuth 2.0 endpoints for now and I’ll cover those in a later post. The other 4 are the ones that are important for allowing your users to use Azure AD for web sign in to an application.
Federation Metadata
The Federation Metadata endpoint is your standard endpoint for auto-configuring the federation trust at the Relying Party. Similar to AD FS, Azure AD exposes the RoleDescriptor elements for WS-Federation and WS-Trust, in addition to the IDPSSODescriptor element for SAML-P 2.0. One difference that you may notice from AD FS is that there’s no SPSSODescriptor element. This is because Azure AD is always acting as an Identity Provider STS, and not a Relying Party STS.
One thing to keep in mind is that when federating some non-Microsoft Relying Parties, you may have to save off a copy of the Federation Metadata file and edit it to remove the RoleDescriptor elements and the XML signature. Some 3rd party applications (such as WebLogic) don’t properly ignore the RoleDescriptors and will therefore not import the metadata file when configuring the trust. The reason you have to remove the XML signature also is because the signature is broken when you remove the RoleDescriptor elements. If you leave the existing signature in place, the Relying Party won’t import it because of the signature mismatch. By removing the signature, you remove the signing check. You are also removing a vital piece of security, by the way. Although, in this case we’re giving the RP a local copy of the file, so the lack of a signature is less of a concern since there’s no notion of a Man in the Middle attack.
WS-Federation
The WS-Federation endpoint is the standard WS-Federation 1.2 protocol. When minting tokens from this endpoint, Azure AD uses the SAML 2.0 format:
This means that if you have an application that uses a SAML 1.1 security token handler, you cannot establish a direct trust with Azure AD. If you need to have the STS for a SAML 1.1 over WS-Fed RP in the cloud, then you’re going to want to use an Access Control Service (ACS) instance to transition the SAML 2.0 token format to a SAML 1.1 token format. One such example is in SharePoint 2010/2013 running in claims mode. The screen shot below is from the web.config file on SharePoint 2013. You’ll see where I’ve pointed out that SharePoint is using a SAML 1.1 token handler. Because of this, if you federate SharePoint 2010/2013 with Azure AD directly, you get an error that says that it doesn’t know how to handle the SAML 2.0 assertion type.
So if your COTS applications use WIF and only support a SAML 1.1 token handler, then you’ll need the following architecture:
SAML-P
The SAML-P endpoints are for minting SAML 2.0 tokens over the SAML 2.0 protocol. Here we have 2 endpoints – one for sign in and one for sign out. When submitting an AuthnRequest to the SAML-P sign in endpoint, the request cannot be signed, as Azure AD does not support SAML authentication request signing. However, when submitting a LogoutRequest to the sign out endpoint, that request does need to be signed. So in order for Azure AD to verify the signature, it has to have a copy of the public key that the Service Provider is using to sign the request with. Now, you’ve probably noticed that there is no place in your published application in Azure AD to upload a certificate. Instead, Azure AD only supports electronic transference of this certificate through a metadata endpoint on the Service Provider. This is configured in the Single Sign On settings section of the published application configuration in Azure AD:
It’s not uncommon for SAML 2.0 Service Providers to have a metadata document at this endpoint that contains the signing key, but not all Service Providers have this. So if you don’t have a metadata endpoint with the public key included, and you want to use the sign-out endpoint, then you have to put in a support ticket so you can transfer that public key to us out of band.
Also, it’s important to note that your WIF-based applications will not be able to use these SAML-P endpoints. WIF does not natively support the SAML 2.0 protocol, only the WS-Federation protocol with SAML 1.1/2.0 assertions. However, a couple of years ago, we released a CTP for SAML 2.0 protocol support for WIF, though it was never released outside of CTP. So more than likely you would be using these endpoints with your non-Microsoft applications, such as Java-based apps running on WebLogic or using something like the Oracle OpenSSO fedlet.
Location-Agnostic Applications
So because Azure AD uses the approach of publishing multiple endpoints that are available both in the Azure cloud and outside of the Azure cloud, Azure AD doesn’t really care where the application lives. Applications that are on-premises, hosted in 3rd party Service Providers, or hosted in the Azure cloud can all take advantage of web sign in through Azure AD. You just need to make sure that the application uses the appropriate endpoint, and also that it uses the endpoint properly.
I’ll be posting more in the future as I run through a few more scenarios that I’m working with, so keep an eye out for more coming down the pipe.