SSO with Azure – some considerations

SSO with Azure – some considerations

Microsoft Windows Azure Active Directory can be used as your Identity Provider (IdP) in the cloud just as you would Active Directory Federation Services (ADFS) on premises.   There is a growing set of features and services available for Authentication and Federation services in Azure.  The easiest and most direct method is to add Applications to your Directory from the Application Gallery.  The “Gallery” is a pre-defined set of application definitions for hundreds of Software as a Service (Saas) applications on the Internet. 

Many, but not all, offer Single Sign On (SSO) with your Azure Active Directory user accounts.  For those that do, setting up SSO with a SaaS application is quick and easy! However, all SaaS apps are not created equal, and their specific handling of certain use cases may or may not work.  Two very important use cases to consider (and test!) are:

  • Deep Links
  • Mobile Apps (on iPhone/iPad and Android in particular)

Deep Links:

An application may send a user an e-mail alert or notification with a link to a particular page within the application context itself.  If the user is already logged into the application, clicking on that link will open the desired page or object.  This type of link that presumes an existing logged on session is popularly referred to as a ‘deep link’.  If the user is not currently logged into the app, a redirection to the login process is issued and once completed (thereby establishing a logged on session) the user is redirected to the initial ‘deep link’.

With SSO authentication models, that means the user must be redirected to the IdP to complete authentication, and then IdP sends the authentication assertion and the ‘deep link’ back to the application for subsequent processing.  That ‘deep link’ is typically passed via the user’s browser in a term/parameter known as RelayState.   Unfortunately (at this time in July 2016) Azure does not support the RelayState method.  For an Azure authenticated user that mean the ‘deep link’ page does not get presented after completing authentication.  Instead, the default page for that user’s account is presented by the application.

All is not lost though!  If the user clicks the ‘deep link’ again, the desired page/object IS presented since a logged on session with the application now exists.

So, it’s an inconvenient user experience for now.  There are cases open with Microsoft and they are working on supporting RelayState to provide the desired seamless experience.

Mobile Apps:

iPhone, iPad, and Android apps are all the rage now and most SaaS applications do offer a mobile client via the associated app stores.  Some of these mobile apps automatically recognize the SSO requirement for the user and ‘do the right thing’.  Some others don’t do it automatically, but can be configured on the mobile device to use a specified IdP to accomplish authentication.  And, sadly, some have no means to engage in an SSO model with any IdP.

The message here is Test and Verify the SaaS application’s mobile app and understand the authentication capabilities before adopting the SaaS application!  A SaaS app that has a mobile app that just doesn’t ‘do’ SSO can lead to a lot of Help Desk calls from the user community, and then a lot of disappointment when they learn it just won’t work for them!

One more thing….

There’s a (growing) set of SaaS applications out there that offer a login option on their home page to use your “O365 Account” to authenticate. The user can click on that button, get passed to Azure for authentication, and then be asked “Do you give us permission to read your directory ?” (or similar question).  By default, *ANY* user can say Yes to that query and the application will add itself to the associated Azure directory application list!  The Administrators for that Azure Directory are NOT notified.  And if you have a different definition and trust already in place for that SaaS application for SSO, it leads to a lot of confusion.  Typically, a user following this method gets a trial/temporary account in the SaaS application that is not associated with any enterprise subscription you may already have in place.

After opening a case with Microsoft and working with their Azure support team, we got to the special PowerShell command that let us turn off that default behavior and now prohibits all users from saying Yes to that question, and the the SaaS application cannot add itself to the Azure tenant’s application list.  Instead, the user gets a message from Azure directing them to contact their Azure administrator.

That PowerShell command is:

Set-MsolCompanySettings -UsersPermissionToUserConsentToAppEnabled $false

Personally, I think the Default condition should be “$false”.

The features and services keep improving and changing, so at some point that may be the case.  For now, if you see a new app in your Azure Directory Applications list – and you know YOU didn’t add it – it’s probably one of these.

Tags:

    Write a Comment

    x

    Contact Us Close