Single Sign On in a Hybrid Data Center Environment
Many businesses today are subscribing to Software as a Service (SaaS) applications instead of implementing their own on-premises instances of custom or published applications. This saves the business the expense of owning and operating the application compute and storage infrastructure, and operating and maintaining the application system software too. There are many SaaS offerings, and it is not unusual for a business to subscribe to several or even many such services. To access these services each user needs an account and password. So, if your business has many subscriptions for applications that all of you users need to access, then folks will need to keep track of unique usernames and passwords for each subscribed service. That is not very user friendly and can lead to bad behaviors from a security perspective with people writing down the usernames and passwords and keeping the printed list ‘handy’. There are also security considerations when a user leaves the business and all of those subscribed application accounts need to be disabled.
Single Sign On
To solve the problem and inconvenience of multiple usernames and passwords for SaaS accounts a technique known as Single Sign On can be used. This uses an individual’s everyday Windows domain username and password to access the SaaS application. That provides for one username and password for all business network and application access. It is convenient for the user, eliminates the bad behaviors that follow multiple accounts, and improve the overall security model for the business.
Most SaaS providers offer Single Sign On capability implemented with the Security Assertion Markup Language 2.0 (SAML 2.0) standard. In that implementation, the business consumer and the SaaS provider define secure and encrypted methods and endpoints to support the authentication of a business user with their Windows domain username and password and assert the results of that successful authentication transaction as an encrypted token with the SaaS provider.
That implemented relationship between the business and the SaaS provider is called Federation – the SaaS provider honors the token presented for the business user’s credentials as proof of the user’s identity. In SAML nomenclature, the business is called the Identity Provider (IdP) and the SaaS provider is called the Service Provider (SP).
For example, the business CPTECH has subscribed to an employee expense processing application provided by XPENBOT.COM. CPTECH and EXPENBOT.COM have established Federation. The login transaction for CPTECH users would then be:
Open https://cptech.xpenbot.com/ with a web browser.
The SP typically provides a customer specific URL for the federated subscribers – this allows the SP to properly configure the IdP endpoints that will be used in the rest of the transaction. This is called SP initiated login.
The user session is redirected to the CPTECH login pages
The IdP login endpoint is used as the destination of the redirection and actually receives a SAML request for authentication of the user.
The user provides the CPTECH Windows domain username and password that they use every day.
Upon successful entry of the username and password, the IdP prepares a SAML response token that is sent back to the user’s web browser
The user’s web browser returns the SAML response token to https://cptech.xpenbot.com
At this point the user’s identity is extracted from the SAML response token and the user is logged in to the XPENBOT application as the identity delivered in the SAML response token
For the user, the experience is just a typical login. But there is actually a lot of data packaging and transfer occurring, all via the user’s web browser.
To accomplish Federated SAML login with a Service Provider (SP) the subscribing business needs to provide an Identity Provider (IdP) service. This can be ADFS installed on-premises, an IdP service from a 3rd party, or Windows Azure if the business also subscribes to a Windows Azure Active Directory enabled service (like Office 365) and has implemented Directory Synchronization with the on-premises Windows domain. In the case of a 3rd party IdP, some type of directory synchronization with the local Windows domain is required too.
To establish Federation, the SP and the IdP trade URLs for Metadata and Endpoints. That’s not an automatic operation. Generally you as the administrator for both your SaaS subscription and the IdP would add the appropriate URLs for Metadata and Endpoints in each service. If you’re using a 3rd party IdP that may be done for you by the IdP provider. The Metadata link provides information about operating details to the other party, and Endpoints are the URLs for Login, Logout, and Reply destinations for those parts of the transaction.
The IdP service acts as a proxy to the business Windows domain for user login credentials, processes the SAML request and response, and provides encryption keys to establish the secure and authenticated Federation relationship. Implementing ADFS on premises is a significant undertaking for many businesses. Using the 3rd party IdP approach is an excellent alternative and relieves the business of all the complexities of operating and maintaining the IdP services, but is an additional expense – typically per user per month. If the business is already an O365 Enterprise plan subscriber, there is an attached IdP service available with the associated Windows Azure Active Directory as part of that O365 Enterprise plan (with some limits and caveats based on the plan level).
Next we’ll review the steps needed to implement IdP services for a SaaS application that support SAML 2.0 logins with Windows Azure and an O365 E3 plan.
Define the Application in Azure
The first step to Single Sign On for a SaaS application with Windows Azure as the IdP for your directory is to define the application in Windows Azure. Visit https://manage.windowsazure.com and log in with and account that is a Global Administrator in the associated O365 E3 plan. Double click on the Directory item listed in the display (that may be all that’s there!), and then click on the Applications item that is in the list across the top on the next page – that will give you this view:
Click on the Add button in the center of the bar at the bottom – that will open the action selection dialogue. There are two methods available to add an application: Choose a predefined application from the Windows Azure Application Gallery, or create your own custom application definition.
The predefined applications are the way to go, but only if they support Windows Azure AD Single Sign On. Unfortunately, that is not revealed until after you’ve added the app and started the configuration. If there’s a gallery entry for the app you need, go ahead and Add it, then click the Configure Single Sign On button – you’ll be presented with a list like:
If that first item “Windows Azure AD Single Sign-On” is not present, dismiss the dialogue and then delete the app definition from your Applications list. You’ll need to configure a custom application (which is next here).
On the other two options, “Existing Single Sign-On” presumes you already have SSO configured for the application with your own ADFS or 3rd party IdP service, and “Password Single Sign-On” just caches the users existing application account username and password to use in automatically populating those fields on the standard non-sso login page for the application. Neither are worthy of any more discussion in this particular post.
So, to add the custom application definition, click that Add button in the bottom bar again and select “Add and application my organization is developing”. On the next panel, give the application a name for reference in your app list, and select the type as “WEB APPLICATION AND/OR WEB API”. In our example, we’ll configure XPENBOT:
On the next panel, Azure wants you to enter the Login URL and the APP ID URI – that last item is an Azure-only identifier. Azure uses it to uniquely identify this application definition in you tenant’s set of applications. For this, I’ve used the Reply-to (aka Relying Party) URL specified by the SaaS application. The completed panel for XPENBOT is:
That returns you to the application page for the newly created XPENBOT app:
There is still more to do – click on CONFIGURE in the list across the top, then scroll down to the “single sign-on” section:
Azure automatically uses the Login URL as the REPLY URL. We need to change that to reflect the actual Reply-to (aka Relying Party) URL provided by the SaaS application – and that’s the same string we used for the APP ID URI. Copy the string from the APP ID URI box above and paste it over the REPLY URL, then hit the SAVE icon in the bottom bar. The page will refresh to:
That completes the configuration steps on the Azure side. We now need to collect some details from that Azure app definition and provide them to the XPENBOT tenant to ‘connect’ the SaaS application tenant with our Windows Azure tenant as the IdP.
Configure the IdP with XPENBOT
SaaS applications will vary in their approach to implementing SAML based Single Sign On. In general they need to know the location of the IdP Metadata, the IdP Login URL, and the item in the returned SAML response that contains the unique identifier for the authenticated user. Declaring the IdP Metadata and Login URLs to the SaaS tenant is often an administrative function available to the business subscriber. These are usually pages in the Set Up or Configuration section of the application console that the business administrator uses. For XPENBOT, we assume that is the case and we need to collect the IdP Metadata URL and the IdP Login URL from our Azure IdP. In the Azure application definition page those items are revealed by clicking on the VIEW ENDPOINTS button on the bottom bar. That presents this page:
For XPENBOT we will copy the FEDERATION METADATA DOCUMENT and the SAML-P SIGN-ON ENDPOINT URLs and paste them into the XPENBOT console configuration pages for those items. The icons at the right end of each item there are handy ‘copy to the clipboard’ buttons for that endpoint.
The other endpoints on that page are for other protocols that a SaaS provider might be using instead of SAML.
The last configuration item for XPENBOT is specifying the item in the SAML response that contains the unique identifier for the authenticated user. That how the application will match the local application account with the authenticated user. In this XPENBOT example, we’re using the User Principal Name (UPN) from the Windows Azure directory. The format is email@example.com and that is the string that would be used in the XPENBOT application when creating a new account for that user.
The SAML response includes data items that are called ‘claims’. The set of claims included in the response from Azure is fixed – meaning the subscribers can’t add or remove items from the claim set. So, in our example the XPENBOT provider will need to be able to adjust how they process the SAML response to extract the unique identifier for the user. The claim set presented by Azure is:
Unique, immutable, non-reusable, directed identifier of the authenticated user for the current application
Identifier for the user in the Azure directory
Identifier of the directory tenant
Given name of the user
UPN of the user
Last name of the user
Identifier of the authority that authenticated the user
The bold claim is what XPENBOT needs to extract as the unique identifier for the authenticated user.
With that configuration step applied at XPENBOT, CPTECH users can now be marked for Single Sign-On in the XPENBOT application and will be redirected to Windows Azure to provide their everyday domain username and password to log on to the XPENBOT application.
The login experience will vary with different applications. Some will provide a URL that puts users directly into the SSO authentication. Others may present an application login page that has an optional link to “Login with your corporate id” or similar phrase. Whatever the approach, the end result is SaaS application access using the business Windows Domain username and password.
Limits and Disclaimers
As noted above, in this example the SaaS provider needs to be able to adjust how they process the inbound SAML claim set to extract the user’s unique identifier. Some SaaS providers are not prepared to do that and mandate that the subscriber business must provide a specific claim item that contains the unique identifier – and may mandate other special claim items as well. That doesn’t fit the scenario considered here. However, Windows Azure does offer another service – Access Control Service – that can be used to customize the SAML claim set presented.
The XPENBOT.COM application referenced here is fictitious but is representative of real world SaaS application configurations deployed with an O365 E3 tenant over the last year.
As always, your experience may vary…..