Password-less 5 of 5: Enabling password-less for 3rd party applications – Part 3

Enable provisioning to 3rd party applications via the Azure AD

In my previous blog post I’ve described how you can discover 3rd party web-based applications which are used in your environment, what options you have to connect them to the Azure AD to make them password-less and I’ve provided two “how-to” examples.

This means our basic setup is working perfect however, to make it brilliant we need to execute some additional steps. These steps are focused around the provisioning and de-provisioning of user accounts and groups within the applications which are connected to the Azure AD.

I hear you thinking “but why do I need to do this? If SAML can do the provisioning, and I disable the user account of the user in AD / Azure AD, the result is the same?” Well yes that’s true, but in general for most of the applications in your environment you will pay a monthly fee for active users these days. Take Slack for example, for each active user you will pay around $17 a month, if my account is disabled in Azure AD my account within Slack is still active, which is a waste of money. Hence the reason why you do need to de-provisioning the accounts within Slack. On the other hand SAML, (if the applications does support user account creation via SAML) will only provision the account at first logon, updates aren’t managed, another reason why you need to enable provisioning.

How does provisioning in Azure AD works?

First of all, the provisioning in Azure AD to these connected web-based applications is based on System for Cross-domain Identity Management (SCIM). By default Azure AD has a SCIM endpoint available in Azure AD for (supported) applications, and is therefore able to talk to your application via the SCIM 2.0 REST API. So, first of all, it’s important to check if the application supports provisioning via SCIM, if it’s an in house developed application make sure that the application supports SCIM by building the SCIM 2.0 REST API for the application.

Once (or if) the application supports SCIM we can use it within the provisioning feature beneath the application in the Azure AD. This will give you the ability to synchronize the attribute values of users and groups to your connected application via the Azure AD.

This will make the Azure AD, besides a central point of authentication / authorization for your application, also the central point of user provisioning to these applications.

For some applications Azure AD already knows there is a SCIM 2.0 REST API endpoint available (i.e. like Slack). This can easily be checked/noticed when, for example, we add the Slack application to the Azure AD beneath the ‘Provisioning’ details, in there you will see ‘Automatic Provisioning supported’. This means that there is already a pre-defined SCIM endpoint for this application available in Azure AD.

When you check i.e. the ‘TOPdesk – Public’ application you will see beneath the ‘Provisioning’ details ‘Automatic provisioning is not supported’. This doesn’t mean TOPdesk doesn’t support SCIM, it basically tells you there is no default SCIM endpoint for it available in Azure AD, so either the application doesn’t support SCIM, or you have to build your own SCIM endpoint within Azure AD / send Microsoft a request to provide SCIM provisioning for the application .

This is, again, a good example why you should pick gallery applications in the Azure AD when available. A big advantage if you would ask me, as you don’t have to build your own SCIM endpoint in Azure AD for Slack when using the gallery application.

Enable provisioning for Slack in Azure AD

Now as we know there is a SCIM endpoint available by default in the Azure AD and in my previous blog post we have connected Slack to the Azure AD for single sign-on and a password experience (what a surprise 🙂 ).  Let’s enable the user provisioning from the Azure AD to Slack via SCIM.

To enable user provisioning, go to the ‘Azure AD blade’ on the Azure Portal. Go to ‘Enterprise Applications’ and search for ‘Slack’.

Within the ‘Slack’ application in Azure AD go to the ‘Provisioning’ tab and hit ‘Get started’.

In the next screen make sure to set the ‘Provisioning Mode’ to ‘Automatic’, more options will appear. As you can see the SCIM endpoint integration is automatically available as there is an authorize button available. Next, hit ‘Authorize’ to provide authorization from the Azure AD to the Slack SCIM API to synchronize user data.

A pop-up window will open, asking you to provide your ‘Slack URL’, this is the tenant name of Slack. Therefore, I’ve filled in my tenant name ‘jacobsaa.slack.com’.

Now ‘sign in to Slack’ with your Slack ‘admin account’ by hitting Sign in with Azure AD.

In the screen below you will see that the Azure AD Provisioning service (or more specifically, the SCIM endpoint) is requesting access to synchronize user data from the Azure AD to Slack. As we trust the Azure AD in this case we will hit the ‘Allow’ button, if we hit cancel we won’t be able to synchronize user data from the Azure AD to Slack.

Once you’ve allowed Azure AD provisioning to Slack, you will be directed back to the Azure AD portal where you can hit ‘Test Connection’ and fill in a ‘Notification Email’. Notification emails are important to turn on as it will inform you as an administrator of any kind of errors once every 24 hours.

NOTE: Don’t forget to hit the checkbox ‘Send an email notification when a failure occurs’ as that will also inform you of any kind of failures.

Once you’ve hit ‘Test Connection’ you need to see a green marked check in the notifications window in the Azure AD. If this isn’t the case, please run through the ‘Authorize’ steps again as something (probably) went wrong.

Now that the provisioning connection to Slack is active, it’s time to make sure to walk through the provisioning configuration. At this time provisioning is still disabled and therefore no data will be exported from Azure AD to Slack. Before we can configure / change the data export we first need to save the configuration before we can alter the ‘Mappings’ configuration, therefore hit ‘Save’.

Once the configuration is saved you will see more options available underneath the ‘Mappings’ option, these are predefined settings as we have chosen for a gallery application. Now to make changes to the configuration for the export of Azure AD groups to Slack please hit ‘Provision Azure Active Directory Groups’.

The attribute mapping screen will open, in here you can define the ‘Source Object Scope’ which can be used to exclude groups from being provisioned within the Slack application. Also, you can configure ‘target object actions’ which defines what to do when an object is created, updated or deleted. Additionally, you will see the ‘Attribute Mappings’ which defines the link between the Azure AD attribute and the Slack attribute.

As, in this example, we don’t want to synchronize groups to Slack let’s make sure the setting ‘Enabled’ is set to ‘No’ and hit ‘Save’.

The next step would be to change / verify the user provisioning settings. Therefore beneath the ‘Mappings’ option, please hit ‘Provision Azure Active Directory Users’. In here we need to make sure that the ‘Enabled’ setting is set to ‘Yes’. Make sure that the ‘Source Object Scope’ is set to ‘All Records’. And at last make sure that all ‘Target Object Actions’ are checked and therefore enabled.

Now we have verified the global settings we can check the Azure AD attribute mapping between the Azure AD attributes and Slack attributes. I.e. if your jobTitle isn’t located in the Azure AD attribute ‘jobTitle’ here you can change the source of that attribute to point to the correct attribute, for example ‘extensionAttributex’. This will make sure users are provisioned correctly in Slack with all required details. Besides the default set, there is always an option to provision other user attributes as well, by hitting the link to ‘Add new mapping’. Please don’t forget to hit the ‘Save’ button in case you’ve changed the configuration.

NOTE: The application will need to be able to “understand” the attributes being provided to it.

Once the group- and user provisioning configuration is saved, it’s time to turn on the user provisioning from Azure AD to Slack (this as we have disabled this for groups as you can see in the print screen below). Once verified that all is okay, toggle the switch for ‘Provisioning Status’ to ‘On’ and hit ‘Save’.

Now when we go back to the ‘Slack Enterprise Application’ in Azure AD and hit the ‘Provisioning’ tab. We can see that one user is successfully provisioned from the Azure AD to Slack. On the right side of the screen you can see there is an automatic ‘Provisioning interval‘ of ‘40 minutes’, meaning all changes are synced every 40 minutes for the users which are in scope for Slack provisioning. On the other side, on top of the window, you can see that you can always hit ‘Stop Provisioning’ to stop this process immediately in case of an emergency or configuration error.

To know what user object(s) is/are currently provisioned we can hit the button ‘View provisioning logs’.

Within the ‘Provisioning Logs’ screen we can see that the user (which was in scope for provision) was updated within Slack. This as the Johny Bravo user existed already on the Slack platform as it was created via the SAML integration described in the previous blog post. The reason why we only see the Johny Bravo user in here, is that this user is the only user which has an active assignment on the Slack application within the Azure AD.

If you want to sync users without an active assignment for that application, we need to change the ‘provisioning settings’ within the ‘Slack Enterprise Application’ in Azure AD.

Within the provisioning settings you can change the ‘Scope’ to either ‘Sync all users and groups’ or ‘Sync only assigned users and groups’. Please keep in mind that this can bring in a tremendous amount of license costs for Slack, hence the reason why I would recommend leaving this setting on ‘Sync only assigned users and groups’.

As I’ve selected ‘Sync only assigned users and groups’ the only users which are synchronized are the members of the ‘Slack-Users’ group.

Now let’s assume you have added a users to this group and don’t want to wait for the 40 minute sync interval, you can also provision one or more specific users on demand by using the ‘Provision on demand’ feature beneath the provisioning settings. Keep in mind that, in case you used ‘Sync only assigned users and groups’, for that to work the user has to be a member of the user-group which you have assigned to the Enterprise Application.

Within the ‘Provision on Demand’ feature, you can provision users ad-hoc. Do this by filling out the search for the user box with the user that you want to add and select the user. Once ready hit ‘Provision’.

If, by mistake or on purpose, the user isn’t a member of the assigned group beneath the application the user won’t be provisioned. In that case you will see that the ‘SkipReason’ is ‘NotEffectivelyEntitled’. Which simply means the user isn’t assigned as a user to the application and therefore provisioning won’t be executed.

If the user becomes a member of the assigned group you can either wait for the 40 minute interval or use the ‘Provision on demand’ feature. Once the provisioning process has been executed you will see in the logs an action for the user which says ‘Create’.

And as you can see within Slack the user is ‘created’ and ready to be used for Slack.

Now when we remove the user from the ‘Slack-Users’ group, you can see that the provisioning process has the action ‘Disable’ within the provisioning logs.

And when looking at the Slack member settings we can also see that the account has now been ‘Deactivated’. This means that, if properly implemented on the application-side, a potential license (which incurs costs) will be removed from the user account in the application. Costs can therefore be decreased in an automated way.

Keep in mind that I strongly urge you to restrict the use of the Slack Enterprise Application for assigned users only. This will help the provisioning process and also help to keep consistency, as the SAML process can also provision a user within Slack. The SAML process will never deprovision a user, however. When this provisioning process is only managed with provisioning via SCIM this scenario can’t happen and therefore will save you a lot of hassle. As you can see below this setting can be found underneath the ‘Properties’ of the ‘Slack Enterprise Application’ and is named ‘User assignment required?’, in my case I’ve set that to ‘Yes’.

You now know how you can use Azure AD provisioning services to provision users from the Azure AD to your 3rd party web-applications which support the SCIM 2.0 REST API. So besides making the application password-less we’ve also made sure that our user estate from Azure AD is synchronized from Azure AD to applications, which makes it even more secure and, from a licensing perspective, easy to manage.

As you have seen in the example above, we have used an Azure AD Gallery app which has the ‘Provisioning’ on the application set to ‘Automatic provisioning supported’. In case the application which you want to enable either has that set to ‘Automatic provisioning is not supported’ or when the Application isn’t listed in the Gallery, this doesn’t mean provisioning isn’t available.

In this case you need to check with your application vendor if they support the SCIM 2.0 REST API. If so, you can still configure provisioning via the Azure AD. This does however requires you to configure some additional details, as Azure AD doesn’t know the SCIM 2.0 REST API URL and Secret Token of your application (that’s what you should retrieve from your vendor).

Lastly, I want to make a call out to all developers in the world which develop web-based applications. Please make sure your application supports SSO based on SAML / OpenIDConnect / Oauth 2.0 and besides SSO also support the SCIM 2.0 REST API. This will for sure help your customers to provide their own identity security and provisioning to the application you develop. Additionally, it will help you as you don’t need to think about a multi-factor authentication solution as that will / can be provided via the SSO methods mentioned above.

For now this was my last planned blog related to the password-less series, if new functionality will be added (which will definitely come in the future), I will add that as a new blog to this series!

I hope you enjoyed reading these blogs about password-less and stay tuned for a new blog series to pop-up very soon:-)!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s