Making Azure AD send group claims is a bit complicated when compared to other IDPs.
The standard AAD group claim (user.groups) will generally send Group IDs instead of the actual group names (e.g "S-1-5-34-676332571-3719947000-8119897876-6655999" instead of "jira-software-users"). The preferred way around this is generally to configure application roles and then use user.assignedroles. This has the added advantage of providing an additional layer of abstraction. As an example, you could map "consultants" and "employees" to the application role "jira-software-users", simplifying your Jira permission scheme.
The main difficulty in setting this up is caused by the lack of a user interface in the Azure admin portal. Defining application roles has to be done by directly editing the application manifest.json file. The manifest can be accessed either through the Azure admin portal or via a REST API which is currently in beta (see https://graph.microsoft.com/beta/servicePrincipals/). We'll use the portal as it's easier than using REST unless you intend to automate the procedure.
For further background on AAD and managed groups, see the Microsoft’s official documentation:
https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-fed-group-claims
https://docs.microsoft.com/en-us/azure/active-directory/develop/howto-add-app-roles-in-azure-ad-apps.
Open the Azure AD manifest file
Log into the Azure admin portal.
Navigate to Azure Active Directory > Enterprise Applications, and locate the Kantega SSO app for which you want group claims.
Open the properties blade and note the name and Application ID:
Now navigate to Azure Active Directory > App registrations. Open the "All applications" tab and find the corresponding registration by using the Application ID from before:
Click on the application in the list and open the Manifest blade to see the JSON manifest. You may edit this directly in the browser, or download the manifest file to your computer, edit the file locally, and then re-upload it with the modifications. It's up to you.
Create application roles in a manifest JSON file
The below example shows how to set up two roles jira-software-users and jira-administrators in the JSON file.
We're going to edit the appRoles section of the manifest in order to add the application roles we want. This is a JSON array, so take care to use valid syntax (it’s very easy to introduce a comma error). Azure won't let you save the modifications unless the JSON is valid.
For the application roles you define, note the following:
The application role name MUST match the corresponding managed group name on the Atlassian side.
You must generate a unique ID for each application role you create (do not use the ids from the example or existing roles). The easiest way is to use a free online GUID generator like https://www.guidgenerator.com/.
The manifest appRoles section before modification:
"appRoles": [
{
"allowedMemberTypes": [
"User"
],
"description": "msiam_access",
"displayName": "msiam_access",
"id": "UUID_DO_NOT_CHANGE",
"isEnabled": true,
"lang": null,
"origin": "Application",
"value": null
}
],
|
And after adding a "jira-software-users" and "jira-administrators" application roles:
"appRoles": [
{
"allowedMemberTypes": [
"User"
],
"description": "msiam_access",
"displayName": "msiam_access",
"id": "UUID_DO_NOT_CHANGE",
"isEnabled": true,
"lang": null,
"origin": "Application",
"value": null
}, /* <-- ADD COMMA AND COPY THE TWO BLOCKS BELOW INTO YOUR OWN JSON FILE AND CREATE TWO UNIQUE GUID VALUES */
{
"allowedMemberTypes": [
"User"
],
"description": "jira-software-users",
"displayName": "jira-software-users",
"id": "<NEW GENERATED UUID>",
"isEnabled": true,
"lang": null,
"value": "jira-software-users"
},
{
"allowedMemberTypes": [
"User"
],
"description": "jira-administrators",
"displayName": "jira-administrators",
"id": "<NEW GENERATED UUID>",
"isEnabled": true,
"lang": null,
"value": "jira-administrators"
}
],
|
Also note the value field is the actual claim value AAD will include in the SAML Response, so it cannot be null or the application role will essentially be useless. You may, of course, add any number of appRoles as your desired permission model requires.
Mapping application roles to group memberships
When the manifest update is successful, the application roles should be defined. You must then map them to users and/or group memberships in Azure AD.
Navigate back to the Azure Active Directory > Enterprise Applications and click on your app in the list. Open the "Users and groups" menu. An empty list of application assignments should be shown.
Select "Add user" to define assignments. Select groups you would like to give an application role in the "Users and groups" area and select jira-software-users as the role. In the example below, users that are members of the jira-users-azure group will receive the jira-software-users application role and SAML claim.
Repeat the same procedure for any other application roles you have.
Now to add the SAML claim itself. Navigate to Enterprise Applications > Kantega SSO for Jira. Open the Single sign-on menu and click "Edit" on the "User Attributes & Claims" section.
Select "Add new claim", and then add a claim using user.assignedroles in Source attribute field as shown in the below example.
CLAIM NAME must be “Role” for Kantega SSO to recognize it in the SAML Response.
Azure AD should now be sending roles whenever users log in, though it sometimes takes a few minutes for these manifest and claims changes to propagate.
Setting up managed groups in Kantega SSO
Now enable managed groups in Kantega SSO if this isn't already the case, then run a new SAML login test. The SAML Response should now contain the application roles that map to the user's groups. The test page should recognize the Role claim and display this in the attribute list. Further down the page, there should be a notification about the unmanaged groups claim, which can be further configured from here.
