Enterprise Mobility and Security Blog

RSS

Howdy folks,

Since we released our application enhancements for Azure Active Directory, we have enabled pre-integrated support for thousands of applications, including over 150 that support single sign-on using the SAML 2.0 protocol. We have enabled support for these applications based on close collaborations with our ISV partners and customers.

Among the application integrations supported by Azure AD, SAML has been far and away the most popular protocol.

So today, I am happy to announce that we have turned on the preview if Self-Service SAML 2.0 configuration for Azure Active Directory. Now customers can configure Azure AD to work with any application that supports service provide initiated SAML 2.0 signin!

To give you the details on how this works, let me introduce Aaron Smalser, the Program Manager who is driving SaaS application integration and management. He written up a nice blog about these new capabilities below.

As always, if you have any feedback or suggestions, we'd love to hear from you.

Best Regards,

Alex Simons (Twitter: @Alex_A_Simons)
Director of Program Management
Microsoft Identity and Security Service Division

 ——————————————————-

Hi,   

I'm Aaron Smalser. Today I'm going to give you a quick tour of our new Self-Service SAML Configuration capabilities.

When we started building out the SaaS app management capabilities of Azure Active Directory, one of our goals was to provide an app integration experience that didn't require you to be an identity specialist to use. This ultimately led to our development of the Azure AD application gallery, and the concept of "pre-integrated" applications. Admins could select pre-integrated apps that they wanted from the gallery, and then complete a simplified step-by-step procedure to enable single sign-on to those apps.

As we worked with our customers and partners on these app integrations, we learned a lot about the types of applications people needed, and how they needed to be deployed. Some of our learnings included:

  • Customers didn't just need single sign-on to SaaS applications, but also their hosted line-of-business and third-party applications deployed to servers they control
  • Many customers had specialty SaaS applications that were difficult to acquire accounts with and test without a joint effort between the Azure AD team, the customer, and the SaaS app provider
  • Many enterprises appreciated the ability to easily configure SaaS apps from the Azure AD app gallery, but also staff people with plenty of knowledge of federation protocols like SAML, and desire the ability to onboard any apps they need in a self-service fashion

So today our team is pleased to announce the ability to configure any application that supports service provider -initiated sign-in using SAML 2.0 for single sign-on with Azure Active Directory.

This can include custom apps that your organization has developed, third-party web applications that your organization has deployed to servers you control, or SaaS applications that you use but have not yet been on-boarded to the Azure AD application gallery.

If you are using any of these types of applications, and have knowledge of or access to their SAML documentation, then we highly recommend checking this out.

Adding an application

To configure an application, sign into the Azure management portal using your Azure Active Directory administrator account, and browse to the Active Directory > [Directory] > Applications section, select Add, and then Add an application from the gallery.

In the app gallery, you can add a custom app using the Custom category on the left, or by selecting the Add an unlisted application link that is shown in the search results if your desired app wasn't found. After entering a Name for your application, you can configure the single sign-on options and behavior.

Quick tip:
As a best practice, use the search function to check to see if the application already exists in the application gallery. If the app is found and its description mentions "single sign on", then the application is already supported for federated single sign-on.

Adding a custom application provides a very similar experience to the one available for pre-integrated applications. To start, select Configure Single Sign-On.

To configure SAML-based authentication select the Windows Azure AD Single Sign-On option (for information about the other options, see this previous blog post). After selecting Next, you will be prompted to enter three different URLs for the application.

The tooltip icons in the dialog provide details about what each URL is and how it is used. After these have been entered, click Next to proceed to the next screen. This screen provides information about what needs to be configured on the application side to enable it to accept a SAML token from Azure AD.

Which values are required will vary depending on the application, so check the application's SAML documentation for details. The Sign-On and Sign-Out service URL both resolve to the same endpoint, which is the SAML request-handling endpoint for your instance of Azure AD. The Issuer URL is the value that appears as the "Issuer" inside the SAML token issued to the application.

After your application has been configured, click Next button and then the Complete to close the dialog.

Assigning users and groups to your application

Once your application has been configured to use Azure AD as a SAML-based identity provider, then it is almost ready to test. As a security control, Azure AD will not issue a token allowing them to sign into the application unless they have been granted access using Azure AD. Users may be granted access directly, or through a group that they are a member of.

To assign a user or group to your application, click the Assign Users button. Select the user or group you wish to assign, and then select the Assign button.

Assigning a user will allow Azure AD to issue a token for the user, as well as causing a tile for this application to appear in the user's Access Panel. An application tile will also appear in the Office 365 application launcher if the user is using Office 365.

You can upload a tile logo for the application using the Upload Logo button on the Configure tab for the application.

Customizing the claims issued in the SAML token

When a user authenticates to the application, Azure AD will issue a SAML token to the app that contains information (or claims) about the user that uniquely identifies them. By default this includes the user's username, email address, first name, and last name.

You can view or edit the claims sent in the SAML token to the application under the Attributes tab.

There are two possible reasons why you might need to edit the claims issued in the SAML token:

  • The application has been written to require a different set of claim URIs or claim values
  • Your application has been deployed in a way that requires the NameIdentifier claim to be something other than the username (AKA user principal name) stored in Azure Active Directory.

For information on how to add and edit claims for these scenarios, check out this article on claims customization.

Testing the application

Once the SAML URLs and certificate have been configured in Azure AD and in the application, users or groups have been assigned to the application in Azure, and the claims have been reviewed and edited if necessary, then the user is ready to sign into the application.

To test, simply sign-into the Azure AD access panel at https://myapps.microsoft.com using a user account you assigned to the application, and then click on the tile for the application to kick off the single sign-on process. Alternately, you can browse directly to the Sign-On URL for the application and sign-in from there.

For debugging tips, see this article on how to debug SAML-based single sign-on to applications.

Tell us what you think!

We'd love to hear from you. Your input will help us ensure that we are delivering a solution that is flexible and helps enable single sign-on to all of the apps you need. If you have any suggestions, questions, or comments, please let us know.

Thanks!
Aaron