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:
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.
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 the valid syntax (comma errors are especially easy to introduce). If not, Azure won't let you save the modifications.
For the application roles you define, note the following:
The manifest appRoles section before modification:
And after adding a "jira-software-users" and "jira-administrators" application roles:
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.
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.
The "claim name" must be Role for Kantega SSO to recognize the Role claim 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.
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. See Group memberships for further details.