I’ve had the opportunity to work on a couple of customer engagements recently integrating SaaS based cloud applications with Azure Active Directory, one being against a cloud-only Azure AD tenant and the other federated with on-premises Active Directory using ADFS. The Azure AD Application Gallery now has over 2,700 applications listed which provide a supported and easy process to integrate applications with Azure AD, although not every implementation is the same. Most of them have a prescribed tutorial on how to perform the integration (listed here), while some application vendors have their own guides.

This blog won’t describe what is Single Sign-On (SSO) or User Provisioning with Azure AD (which is detailed here), but rather to highlight some things to consider when you start planning your application integrations with Azure AD.

User provisioning into the application

Azure AD supports user provisioning and de-provisioning into some target SaaS applications based on changes made in Windows Server Active Directory and/or Azure AD. Organisations will generally either be managing user accounts in these SaaS applications manually, using scripts or some other automated method. Some notes about provisioning in Azure AD:

  • ‘Featured’ apps in the Azure AD Application Gallery support automatic provisioning and de-provisioning. A privileged service account with administrative permissions within the SaaS application is required to allow Azure AD the appropriate access
  • Some applications (i.e. like Lucidchart and Aha!) are able to perform the function of provisioning of new users on their own, which is managed directly by the application with no control from Azure AD. Some applications (i.e. like Lucidchart) will also automatically apply a license to the new user account, which makes the correct user assignment to the application important. Other applications (i.e. like Aha!) will automatically create the new accounts but not assign a license or provide access to any information. License assignment in this case would be a manual task by an administrator in the target SaaS application
  • All other applications that do not provide the capability for automatic provisioning require the user accounts to be present within the target application. User accounts will therefore need to be either manually created, scripted, or make use of another form of Identity Management. You need to ensure the method on how the application matches the user from Azure AD is known so that accurate matching can be performed. For example, the ‘UserPrincipleName’ value from the Azure AD user account matches the ‘NameID’ value within the application

Role mapping between Azure AD and the application

Access to applications can be assigned either directly against user accounts in Azure AD or by using groups. Using groups is recommended to ease administration with the simplest form using a single Security Group to allow users access to the application. Some applications like Splunk support the capability to assign user access based on roles which is performed using ‘Role Mapping’. This provides the capability to have a number of Security Groups represent different roles, and assigning users to these groups in Azure AD not only enables access to the application but also assigns the user’s role. Consider how you manage user memberships to these groups, how they are named so that they are easily identified for management, and how the application knows about the groups. Splunk for example requires groups to be created using the ‘Group Object Id’ of the Azure AD group and not it’s name, as shown in this example:

The Group Object Id for groups can be found by going to your Directory Page and then navigating to the group whose Object Id is to be retrieved.


User interface changes

Some applications have a modified interface when SSO is enabled, allowing users to select whether to login with userID/password credentials or a federated login. You need to consider end-user communications for any sudden changes to the application that users may face and let them know which option they should select. For example, the Aha! application changes from this:

to this when SSO is enabled:

Have a backout plan

In addition to the point above, some applications require an all-or-nothing approach when SSO is enabled. If you have not sufficiently planned and prepared, you may be locked out of the application as an administrator. If you have access to a test subscription of your application, test, test and test! If you only have your production subscription, I would suggest having an open dialog with the application support team in case you inadvertently lock yourself out of authenticating. For example, the New Relic application allows the SSO configuration to be made in advance which then requires only the account owner to enable it. Once enabled, all authentication is using SSO and you had better hoped the configuration is correct or else you’ll be asking support to backout the changes.

Applications such as ServiceNow have the ability to have multiple SSO providers where you can implement a phased approach for the enabling of SSO to users with the ultimate goal to make SSO authentication default. ServiceNow also has a ‘side door’ feature where you can by-pass external authentication and login with a local ServiceNow user (as detailed here).

Accessing applications

Users will be able to access applications configured for SSO with Azure AD using either of the following methods:

  • the Microsoft MyApps application panel (https://myapps.microsoft.com)
  • the Office 365 application launch portal
  • Service Provider Initiated Authentication, where authentication is initiated directly at the SaaS application

Most federated applications that support SAML 2.0 also support the ability for users to start at the application login page, and then be signed in through Azure AD either by automatic redirection or by clicking on a SSO link to sign in as shown in the Aha! images above. This is known as Service Provider Initiated Authentication, and most federated applications in the Azure AD Application Gallery support this capability. Some applications such as AWS do not support Service Provider Initiated Authentication and SSO does not work if users attempt to authenticate from the application’s login screen. The alternate methods to access the application via SSO need to be followed and communication for end-users to inform them on how to access these types of applications. For AWS, you can access the application using SSO from the MyApps application panel, with an alternate method by providing users with a ‘Single Sign-On URL’ which can be used as a direct, deep link to access the application (as detailed here).

Conclusion

Hopefully you can see that although it can seem quite simple to integrate an application with Azure AD, take the time to plan and test the integration of your applications.

Category:
Azure Infrastructure, Identity and Access Management, Security
Tags:
, , , , , , , ,

Join the conversation! 3 Comments

  1. Hi David,
    Great to here provisioning in action, did you see any issues with the provisioning from Azure AD to the application.
    We are seeing extremely slow provisioning times; more than 48 hours to provision 1000 users for workplace by facebook app.

    Regards
    Andrew

  2. Hello

    Will service provider initiated signin also not work for a SAML app if we use Office 365 and have federated identity with ADFS? The service provider initiated signin for SAML app still goes to ADFS, but works via My Application panel.

  3. Hi there,
    I read somewhere in a site comment that it is not possible to have Single Sing On SaaS Integration with multiple instances of an AWS App. Do you know details about this and would this be an issue with any multi instance Connection of a SaaS Service?
    Thanks,
    Franck

Comments are closed.