The main driver for this post was a project I had started to migrate all of our applications that were currently using Okta as an Identity Source to Azure Active Directory. An Identity Source is authentication mechanism that you can use instead of the defaults that the application provides. If you also use Office 365 you probably use Azure AD for Single Sign On (SSO) already. This can be extended to other applications such as Salesforce not just for Office 365.
The reasons for this were mainly financial as we had already paid for Office 365 E3 + EMS licences. We therefore had the identity services built in already so it didn’t make sense to continue to pay Okta for the same service. I will go through setting up a number of applications in Azure AD including; AWS Console, BlueJeans, Concur, Dynatrace, Litmos, EmPerform, PeopleHR, Salesforce and Secret Server. All applications use SAML and we will go through the configuration for each individual application below.
AWS Console
The following guide from Microsoft was used to perform the setup
1. Create a new application by going into the Azure Active Directory Admin Center and clicking Enterprise Applications. Then click New application.
2. Under the Add from the gallery section type AWS and choose the Amazon Web Services (AWS) app
3. Give the application a name or use the default then click Add
4. Go back to Enterprise applications and open the Amazon Web Services app
5. Click Single sign-on, then choose the SAML button
6. Click the edit button under step one.
7. The Identifier URL and the Sign on URL are automatically filled in, click Save
8. Click the edit button under step 2
9. You will need to add three claims as below
To do this click Add new claim and fill in as below.
You should add three new claims as the table below shows:
| Name | Source Attribute | Namespace |
|---|---|---|
| RoleSessionName | user.userprincipalname | https://aws.amazon.com/SAML/Attributes |
| Role | user.assignedroles | https://aws.amazon.com/SAML/Attributes |
| SessionDuration | "provide a value between 900 seconds (15 minutes) to 43200 seconds (12 hours)" | https://aws.amazon.com/SAML/Attributes |
10. Under step 3 download the federation metadata XML and store somewhere safe
11. Click Azure Active Directory then click App registrations and select the Amazon Web Services App
12. Select API permissions
13. The permissions need to be configured as below. Notice the difference between the Azure Active Directory Graph permissions and the Microsoft Graph permissions – there are also the Delegated and Application types.
To add a permission click Add a permission. Select the type:
Microsoft Graph
Azure Active Directory Graph
Choose the permission type:
Then select the actual permission:
14. You now need to login to your AWS console to complete the configuration. Login and select IAM.
15. Click Identity Providers and click Create Provider
16. Change the provider to SAML and type a provider name. Then choose the file you just downloaded from Azure AD. Then click Next and then Create.
17. Go to identity providers and click the newly created provider. Copy the Provider ARN.
18. We now need to apply the new Azure AD Identity provider to our existing roles. If you do not have any roles you can create some that suite your needs. A basic setup could include an Admin/Power user, Read-only user and a helpdesk user. Later on we will be assigning these roles to Active Directory groups so that anyone in the group has the permissions. If you used a previous SSO provider (such as Okta) you will be changing from this to Azure. Select Roles and choose a role that has Identity Provider as the Trusted entity.
19. Click trust relationships and then click Edit Trust relationship
20. Paste in the Identity Provider ARN that you copied from step 14 under the federated section.
21. You can also have multiple identity providers if needed which may make migrations easier:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": [
"arn:aws:iam::256985412365:saml-provider/Okta-MultiRole",
"arn:aws:iam:: 256985412365:saml-provider/Azure"
]
},
"Action": "sts:AssumeRoleWithSAML",
"Condition": {
"StringEquals": {
"SAML:aud": "https://signin.aws.amazon.com/saml "
}
}
}
]
}
22. You now need to import the AWS roles into Azure AD so that you can assign them to users/groups. To do this first open Azure AD Graph Explorer by going to this link
23. Click Sign in with Microsoft to login to your instance.
24. Click modify permissions
25. Change the permissions so that the below are all consented.
26. Change the dropdown version to Beta
27. In the address bar enter:
https://graph.microsoft.com/beta/servicePrincipals/ You can get the application object ID by going to Enterprise Applications> Amazon Web Services (AWS)> Properties> Object ID
The link should look something like this:
https://graph.microsoft.com/beta/servicePrincipals/2928624c-c828-4e29-bea9-a11b62bec71d
28. Copy and paste the link into the address bar and then click Run Query. You should see the full list of service principals below:
29. In among this data you should see the current appRoles.
30. You now need to add the application roles you have within AWS to the Microsoft Graph Explorer. To do this you need to create some JSON code that includes all of the roles from AWS. I should note that you should not set the Amazon application in Azure AD to Automatic provisioning if you have more than one account. This is because automatic provisioning will pull in the roles from the account that you have logged into and that account alone. If you have multiple accounts, you need to create the JSON manually which needs manual provisioning set.
Below is an example of the JSON used to bring across the Mydomain.Test.PowerUser, Mydomain.Test.ReadOnly and Mydomain.Test.ServiceDesk roles from AWS to Azure AD.
{
"appRoles": [
{
"allowedMemberTypes": [
"User"
],
"description": "msiam_access",
"displayName": "msiam_access",
"id": "b9a00992-8844-41c1-89d7-6858613e722b",
"isEnabled": false,
"origin": "Application",
"value": null
},
{
"allowedMemberTypes": [
"User"
],
"description": "Mydomain.Test.PowerUser",
"displayName": "Mydomain.Test.PowerUser,Azure",
"id": "91c0fece-6b8e-4650-9362-681bfb9fea20",
"isEnabled": true,
"value": "arn:aws:iam::256985412365:role/Mydomain.Test.PowerUser,arn:aws:iam::256985412365:saml-provider/Azure"
},
{
"allowedMemberTypes": [
"User"
],
"description": "Mydomain.Test.ReadOnly",
"displayName": "Mydomain.Test.ReadOnly,Azure",
"id": "a08ba217-f7fb-4d4e-9b84-890e7d1b3d12",
"isEnabled": true,
"value": "arn:aws:iam::256985412365:role/Mydomain.Test.ReadOnly,arn:aws:iam::256985412365:saml-provider/Azure"
},
{
"allowedMemberTypes": [
"User"
],
"description": "Mydomain.Test.ServiceDesk",
"displayName": "Mydomain.Test.ServiceDesk,Azure",
"id": "f09444d3-8f09-4a73-9867-30ff23922dd1",
"isEnabled": true,
"value": "arn:aws:iam::256985412365:role/Mydomain.Test.ServiceDesk,arn:aws:iam::256985412365:saml-provider/Azure"
}
]
}
Some things to note:
• This will replace all the appRoles you currently have with what is in the JSON so they all need to be in there
• You need to ensure you include the below as the first appRole:
{
"allowedMemberTypes": [
"User"
],
"description": "msiam_access",
"displayName": "msiam_access",
"id": " b9a00992-8844-41c1-89d7-6858613e722b ",
"isEnabled": false,
"origin": "Application",
"value": null
},
31. You may get an error stating that the roles cannot be updated or deleted unless they are disabled. If this is the case you need to disable the msiam_access role in the manifest file for the application. To do this go to Azure Active Directory> App registrations> Amazon Web Services (AWS)> Manifest
32. Change the “isEnabled” part to false as below, then click Save
33. I found that the best process to create the appRoles JSON code was to start with a template as below:
34. Then login to the console for the account you want to get the roles from. Click Roles and go into one of the roles using the Azure identity source. Click the copy button next to the Role ARN.
35. Paste the Role ARN over the value in the template, also update the description and the display name.
36. Click the Trust relationships tab and copy the Azure trusted entity as below
37. Do a find and replace in the template replacing the existing value with the copied value from the Trust relationships tab
38. You now need to enter the ID numbers for each of your appRoles. I use the GUID from the AD group that will be assigned to the AWS role for this ID number. To get the Azure AD group GUID go to Azure Active Directory> All Groups> Type the name of the groups that you will be assigning to the appRole. Copy the object ID of the group and paste it into the corresponding appRole in your JSON code.
39. Go back to Microsoft Graph Explorer here then enter your service principal with your object ID https://graph.microsoft.com/beta/servicePrincipals/865cea61-251b-4e08-bed1-2e6f6f7ade8e
40. Change the dropdown to patch and then paste in your appRoles to the request body. Click Run Query to upload the roles.
41. You can now assign your Azure AD groups to the application to provide user access. Go to Enterprise Applications> Amazon Web Services (AWS)> Click Users and groups> Click Add user> Click Users and groups> Select the group that is to have access
42. Click Select Role and choose the role that corresponds to the AD group you just selected. This will determine the account/permissions the user has in AWS.
43. We now need to configure a conditional access rule to force AWS users to use MFA when logging in. First users that are to use MFA need to register here https://aka.ms/mfasetup
First ask the users to download the Microsoft authenticator app. Then ask then to configure the registration page as below:
44. Now open Conditional Access from the Azure portal
45. Click New Policy
46. Add the users that are to be affected by the policy
47. Add the AWS Application to the scope
48. Set the Access controls to Grant Access but require MFA as below
Bluejeans
The following guide from Microsoft was used to configure Bluejeans
1. Create a new application by going into the Azure Active Directory Admin Center and clicking Enterprise Applications. Then click New application.
2. Under the Add from the gallery section type Bluejeans and choose the Bluejeans app
3. Give the application a name or use the default then click Add
4. Go back to Enterprise applications and open the Bluejeans app
5. Click Single sign-on, then choose the SAML button
6. Click the edit button under step one
7. Enter the URLs as below:
8. From step 3 download the Certificate (Base64) file
9. Copy the URLs from step 4 as below
10. Login to Bluejeans as an admin. Click the Admin button.
11. Click Group Settings> Security
12. Select SAML Single Sign On and choose Enable automatic provisioning
13. Click Choose file and upload the certificate you downloaded from Azure
14. In the Login URL textbox, paste the value of Login URL which you have copied from Azure portal.
In the Password Change URL textbox, paste the value of Change Password URL which you have copied from Azure portal.
In the Logout URL textbox, paste the value of Logout URL which you have copied from Azure portal.
15. In the User Id textbox, type http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name
In the Email textbox, type http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name
Click SAVE CHANGES.
16. The last step is to open the Azure console and go to Users and Groups. From here you can assign the application to a group as below.
Concur
The following guide from Microsoft was used to perform the setup
1. Create a new application by going into the Azure Active Directory Admin Center and clicking Enterprise Applications. Then click New application.
2. Under the Add from the gallery section type Concur and choose the Concur app
3. Give the application a name or use the default then click Add
4. Go back to Enterprise applications and open the Concur app
5. Click Single sign-on, then choose the SAML button
6. Click the edit button under step one and complete as below:
7. From step 3 download the Federation Metadata XML file
8. Copy the URLs from step 4:
9. As per the Microsoft article, contact the Concur support team for the next step. You will need to send them the Metadata XML file and the URLs collected from Azure.
10. As with the previous apps you now just need to assign some users within the Azure portal and test
Dynatrace
1. Open the Azure console and click Enterprise Applications then click Non-gallery application. Type in the name for the Dynatrace application.
2. Click Single sign-on, then choose the SAML button
3. Under step 1 click edit and configure the URLs as below
4. Ensure that the claims match those used in Dynatrace, we had to pick user.onpremisessamaccountname as the unique identifier as this is what we had used
5. Download the Federation Metadata XML
6. Login to the Dynatrace console and click User authentication
7. Click Single Sign-on settings
8. Change the drop-down to SAML 2.0
9. Click Select file and upload the Federation Metadata XML file that you downloaded from Azure
10. In the respective text fields, type in the user attributes for first name, last name, and email, based on SAML 2.0 response attributes.
11. Initially we found that the XML file was being rejected. After discussing with Dynatrace support they advised us to add the below lines to the file:
<NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</NameIDFormat>
<NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</NameIDFormat>
<NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</NameIDFormat>
<NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</NameIDFormat>
So it should look like this:
12. You can now go back to the Azure console and assign some users to the app for testing.
Litmos
The following guide from Microsoft was used to configure Litmos
1. Create a new application by going into the Azure Active Directory Admin Center and clicking Enterprise Applications. Then click New application.
2. Under the Add from the gallery section type Litmos and choose the Litmos app
3. Give the application a name or use the default then click Add
4. Go back to Enterprise applications and open the Litmos app
5. Click Single sign-on, then choose the SAML button
6. Click the edit button under step one and configure the URLs as below
7. Click the edit button under step 2 and create the claims as below
8. Download the Federation Metadata XML from step 3
9. Click Azure Active Directory then click App registrations and select the Litmos App
10. Select API permissions
11. The permissions need to be configured as below. Notice the difference between the Azure Active Directory Graph permissions and the Microsoft Graph permissions – there are also the Delegated and Application types.
To add a permission click Add a permission. Select the type:
Microsoft Graph
Azure Active Directory Graph
Choose the permission type:
Then select the actual permission:
12. Login to Litmos as an admin, then click Account Settings
13. Click Integrations
14. Click SAML 2.0 (Single Sign On)
15. Open the metadata XML file from Azure and remove the below line from the file:
<?xml version=”1.0″ encoding=”UTF-8″?>
Copy and paste the text into the SAML Metadata field an click Save changes.
16. You can now assign some users from the Microsoft Azure console to the application and test.
EmPerform
1. Open the Azure console and click Enterprise Applications then click Non-gallery application. Type in the name for the EmPerform application.
2. Click Single sign-on, then choose the SAML button
3. Under step 1 click edit and configure the URLs as below
4. Ensure that the claims match those used in EmPerform, note that user.onpremisessamaccountname had to be used for the name and nameidentifier
5. Under step 4 copy the Login URL and send this to EmPerform support. They will add this service URL to the system.
6. Click Azure Active Directory then click App registrations and select the Litmos App
7. Select API permissions
8. The permissions need to be configured as below. Notice the difference between the Azure Active Directory Graph permissions and the Microsoft Graph permissions – there are also the Delegated and Application types.
To add a permission click Add a permission. Select the type:
Microsoft Graph
Azure Active Directory Graph
Choose the permission type:
Then select the actual permission:
9. You can now assign some users from the Azure AD console and test
PeopleHR
The following guide from Microsoft was used to perform the setup
1. Create a new application by going into the Azure Active Directory Admin Center and clicking Enterprise Applications. Then click New application.
2. Under the Add from the gallery section type People and choose the PeopleHR app
3. Give the application a name or use the default then click Add
4. Go back to Enterprise applications and open the PeopleHR app
5. Click Single sign-on, then choose the SAML button
6. Click the edit button under step one and complete as below:
The format for this is listed as below:
In the Sign-on URL text box, type a URL using the following pattern: https://<company name>.peoplehr.net
In the Identifier box, type a URL: https://www.peoplehr.com
In the Reply URL text box, type a URL using the following pattern: https://<company name>.peoplehr.net/Pages/Saml/ConsumeAzureAD.aspx
7. From step 3 download the Federation Metadata XML file
8. Copy the URLs from step 4:
9. The next step is to contact the PeopleHR support team to configure SAML at their end. You will need to send them the Metadata XML file and the URLs collected from Azure.
10. As with the previous apps you now just need to assign some users within the Azure portal and test
Salesforce
The following guide from Microsoft was used to perform the setup
1. Create a new application by going into the Azure Active Directory Admin Center and clicking Enterprise Applications. Then click New application.
2. Under the Add from the gallery section type Salesforce and choose the Salesforce app
3. Give the application a name or use the default then click Add
4. Go back to Enterprise applications and open the Salesforce app
5. Click Single sign-on, then choose the SAML button
6. Click the edit button under step one and complete as below:
The guide lists these values as the below:
In the Sign-on URL textbox, type the value using the following pattern:
Enterprise account: https://<subdomain>.my.salesforce.com
Developer account: https://<subdomain>-dev-ed.my.salesforce.com
In the Identifier textbox, type the value using the following pattern:
Enterprise account: https://<subdomain>.my.salesforce.com
Developer account: https://<subdomain>-dev-ed.my.salesforce.com
7. From step 3 download the Federation Metadata XML file
8. Copy the URLs from step 4:
9. Click Azure Active Directory then click App registrations and select the Salesforce Services App
10. Select API permissions
11. The permissions need to be configured as below. Notice the difference between the Azure Active Directory Graph permissions and the Microsoft Graph permissions – there are also the Delegated and Application types.
To add a permission click Add a permission. Select the type:
Microsoft Graph
Azure Active Directory Graph
12. Choose the permission type:
13. Then select the actual permission:
14. Open a new tab in your browser and sign in to your Salesforce administrator account
15. Click on the Setup under settings icon on the top right corner of the page.
16. Scroll down to the SETTINGS in the navigation pane, click Identity to expand the related section. Then click Single Sign-On Settings.
17. On the Single Sign-On Settings page, click the Edit button.
If you are unable to enable Single Sign-On settings for your Salesforce account, you may need to contact Salesforce Client support team.
18. Select SAML Enabled, and then click Save.
19. To configure your SAML single sign-on settings, click New from Metadata File.
20. Click Choose File to upload the metadata XML file which you have downloaded from the Azure portal and click Create.
21. On the SAML Single Sign-On Settings page, fields populate automatically and click save.
22. On the left navigation pane in Salesforce, click Company Settings to expand the related section, and then click My Domain.
23. Scroll down to the Authentication Configuration section, and click the Edit button.
24. In the Authentication Configuration section, Check the AzureSSO as Authentication Service of your SAML SSO configuration, and then click Save.
25. As with the previous apps you now just need to assign some users within the Azure portal and test
Secret Server
1. Open the Azure console and click Enterprise Applications then click Non-gallery application. Type in the name for the Secret Server application.
2. Click Single sign-on, then choose the SAML button
3. Login to the Secret Server console and click Admin
4. Click Configuration and then click SAML
5. Verify that you can login using the below link which will avoid using SSO in case of any issues.
6. Click Edit and then check SAML enabled then click Save
7. Then click Download Service Provider Metadata (XML)
8. Next go back to Azure AD and click upload metadata file. Select the file you just downloaded from Secret Server.
9. Ensure that all the URLs appear as below for step one:
10. Ensure that all the claims from step 2 match the below
11. Click to download the Federation Metadata XML file from step 3
12. Go back to the Secret Server console SAML settings and click Create New Identity Provider
13. Click Import IDP from Metadata and select the file you downloaded from Azure AD
14. You can now go back to the Azure console and assign some users to the app for testing.
