In my previous blog post I already explained how you are able to automate provisioning of regular users to 3rd Party applications. And in another blog post I’ve described how you can maintain your guest user lifecycle. But what about maintaining guest users who are active in 3rd party applications connected to your Azure AD, which is getting more and more common?
This blog will help you explain how you can easily get in control of the guest user lifecycle in 3rd party applications, like Slack. Whereby we will use SCIM for provisioning, SAML for SSO and an Access Package to easily maintain the lifecycle of the guest identity within the Slack application.
This is important as for most 3rd party applications you pay a monthly fee for active users these days, in case of Slack this is about $17 per active user per month. By using an Access Package for guest users for applications like this, you can easily get into control of access (and costs) to these applications for your guest users. Besides you can put solid approval flows on requesting access to these applications as well, including recurring access reviews.
Now before we are going to configure the Access Package, let’s first make sure that the provisioning settings and Single Sign-on configuration is in place before continuing with the access package configuration. This is crucial to have as otherwise users can’t be deprovisioned automatically in these applications. So, if you haven’t done that yet, please read these other two blog post first and implement the required configuration steps before continuing.
Now we are ready, let’s head over to the configuration of the Access Package
Access Package configuration for 3rd party applications
Now the application and provisioning for the Slack application has been configured, we first need to make sure that once people are requesting access to the Slack application, they are required to put in some additional information to ‘enrich’ their guest user identities.
This as by default the ‘Firstname’ and ‘Lastname’ aren’t populated automatically on guest user identities, that would indicate that those details won’t be available as well in Slack, hence the reason why this needs to be configured first. To do this, go to Azure Active Directory –> Identity Governance –> Catalogs and select the catalog where the application resides in or should reside in. If the application hasn’t been added to the Catalog add it first by hitting ‘Add Resource’.
NOTE: Catalogs can be used to delegate control over the resources within the catalog to for example end users. If that’s not what you desire, you can add the application to the general catalog. Please do note however that there currently isn’t an option to move access packages (with attached resources) between catalogs.
Once the application has been added, select the ‘Slack’ application, and hit ‘Require Attributes’.
Now add the attributes you need to have in the Slack application as well, in my case I only made the ‘Givenname (Firstname)’ and ‘Surname (Lastname)’ required as input fields. These input field are shown to the user when requesting access to the application, and once access is approved the input the user provided is populated on the guest account. Once ready, hit ‘Save’.
Now the application settings within the Catalog have been configured, let’s start with creating an Access Package. Go to the Azure Active Directory –> Identity Governance –> Access Packages and hit ‘New Access Package’. Fill in the ‘Name’ and ‘Description’ of the access package, which is shown to end users, select the catalog (which contains the Slack application we just added) and hit ‘Next: Resource Roles’.
Now add the Slack application as resource to this access package and make sure to select the role ‘User’. Once ready, hit ‘Next: Requests’.
In the next pane, make sure to select ‘For users not in your directory’ and select one of the options, in my case I’ve specifically selected ‘Specific connected organization’ and added the ‘InSpark’ organization. This means users within the ‘InSpark’ tenant can request access to this Slack application. This to prevent anyone in the world being able to request access to my Slack application and me getting spoiled by approval requests :-).
NOTE: Need to know how to add a Connected Organization, please read this instruction from the Microsoft Docs.
Beneath the ‘New access package’ settings make sure that ‘Require approval’ and ‘Require request justification’ are set to ‘Yes’ (this to prevent users from automatically being added). Choose how many approver stages you want to have and select the approver(s). In my cases I’ve selected a single approver stage, whereby the approver has 14 days to approve and must provide a justification for approval. At last, make sure that ‘Enable new requests’ is set to ‘Yes’, to make sure people can actually request access, and hit ‘Next: Requestor Information’.
Within the Requestor information tab, we can ask custom questions, in my case I’ve added the question ‘For which purpose do you need access to Slack?’, this with a ‘long text input’ and made it required.
When we switch to the ‘Attributes’ tab we can see that these attributes have been already made required (as we have added them earlier). Important to note is that when you require different attributes to be populated you can’t do this via the Access Package but need to put them on the resource in the catalog. Once ready hit ‘Next: Lifecycle’.
One of the last steps is to configure the expiration and access review settings. In this example I’ve decided not to put an expiration on the access package but use an Access Review which runs once bi-annually for 30 days. In this case the reviewer is the same as the approver, but you can of course go nuts and select something completely different here. Once ready again hit ‘Next: Rules’ and hit ‘Next: Review + Create’.
Now review you’re the settings and hit ‘Create’ once you’re ready!
Now if we go to the MyAccess page with an account from the connected organization we can see that we can request the application by hitting the ‘Request’ button.
We can see that the questions and attributes we just required to be configured are shown and can be filled in by the requestor. Besides as this guest identity needs to be provisioned into this tenant as a guest user, we need to accept that details will be shared with this environment so a guest user can be created. Once ready hit ‘Submit’.
NOTE: If the guest user already exists in your tenant the provided values for the attributes ‘Firstname’ and ‘Lastname’ will be updated on the guest user identity in Azure AD, once the request is approved!
The approver will now get an email for approval, which contains a link to the portal below, and is from this portal able to approve or deny the request. Therefore, fill in a ‘reason’ for, in this case, approval and hit ‘Approve’.
Now if the guest user didn’t exist, the guest user will be created in the tenant and will be added as a user directly beneath the Slack application. This can be seen below.
If we are going to look in the provisioning logs beneath the application, we can see that the user is created and then updated.
Looking at the details we can see as well that the givenName and surname attributes as provided by the end user are synced over to the Slack application during provisioning. By using this process, we therefore not only enrich the Guest user identity within the Azure AD but enrich the data in Slack as well!
Now the user has been provisioned into Slack, the user is able to use the application with his guest identity! He can therefore go to MyApps (don’t forget to switch to the resource tenant) and is able to launch the Slack application (using the direct URL to Slack is an option as well).
As the user was already logged in, the sign-in experience to Slack is seamless and the user is now able to work with his / her Guest identity in Slack.
Now after a while the Access Review is triggered and the reviewer (in this case same as the approver) denies the access review, wherefore the user first gets removed from the Slack application as a user. If we after the removal have a look at the provisioning logs, we can see that the user has been disabled in the Slack application, this means the user won’t consume a Slack license anymore.
And secondly as the user was provisioned via the Access Package process and the user lost his last ‘access package assignment’ the user is blocked for signing in and will be removed from the tenant 30 days later.
We can confirm as well that this has been initiated by the Azure AD Identity Governance process via the Audit Logs beneath the guest user identity in Azure Active Directory.
The above process will therefore as you can see mange the full Identity lifecycle management from Azure AD to Applications and the other way around by only using Azure AD tooling. It will get you from the maintenance seat back again to the driver’s seat so don’t wait any longer and start today! There are so many things whereby Azure AD Identity Governance can help you speed up, stay secure and in control of your environment.
After you’ve followed the above steps and steps from my previous blogs you have now implemented a strong and solid lifecycle management solution for guest users in 3rd party applications connected to the Azure AD. You know what it takes to connect an application to the Azure AD, enable the application with Provisioning from the Azure AD and you can create an Access Package for it as well. This will, besides providing more self-service, less license and maintenance costs, improve the security posture within your tenant as well around guest accounts!
In my next blog we will have a look at the ‘hidden gems’ of the Entitlement Management within Identity Governance (in short Access Packages). Whereby you can think of ‘Separation of Duties’, ‘Custom Extension’ and more.
I hoped you enjoyed reading this new blog within the Azure AD Identity Governance series! Stay tuned for my next Azure AD Identity Governance blog soon :-).
- An Introduction to Azure AD Identity Governance
- Identity Governance 1 of 8: Implementing a Strong Identity Foundation
- Identity Governance 2 of 8: Implementing Identity Lifecycle management for guest users – part 1
- Identity Governance 2 of 8: Implementing Identity Lifecycle management for guest users – part 2
- Identity Governance 2 of 8: Implementing Identity Lifecycle management for guest users – part 3
- Identity Governance 3 of 8: Configuring Provisioning in 3rd party apps for (guest) users
- Identity Governance 4 of 8: Configuring Entitlement Management
- Identity Governance 5 of 8: Implementing Access Reviews
- Identity Governance 6 of 8: Implementing Privileged Identity Management
- Identity Governance 8 of 8: Review by Monitoring and reporting
- Identity Governance 9 of 8: Implementing Identity Lifecycle management for employees