Azure AD integration as an IDP with AWS Cognito

Amazon Cognito provides authentication, authorization, and user management for your web and mobile apps. Your users can sign in directly with a user name and password, or through a third party such as Facebook, Amazon, or Google.
The two main components of Amazon Cognito are user pools and identity pools. User pools are user directories that provide sign-up and sign-in options for your app users. Identity pools enable you to grant your users access to other AWS services.

– AWS Docs

In this article I’m going to talk about integrating Azure Active directory as an Identity Provider in AWS Cognito. There are multiple ways to integrate Azure AD single sign on with your Cognito application each with its pros and cons.

• Azure AD integration with Cognito using SAML2.0 – Only users which exist in the active directory can sign in. It’s currently not possible to allow other active directory users.
• Azure AD integration with Cognito using OpenID Connect – Configurable so as to allow users in either current active directory only or any active directory.

Prerequisites

• Azure account with premium features or premium trial.
• Existing Cognito user pool.
• Tenant ID for Azure Active directory from which users will be allowed to login (Only for OIDC).

SAML2.0 – Integrating Azure AD as IDP in Cognito

This consists of 2 parts, first we need to create an Azure AD Application and second we need to integrated our newly created Azure AD application with AWS Cognito.

Create an Azure AD Application

1. Go to Azure Portal -> Azure Active Directory -> Enterprise Applications.
2. Create an Azure AD Enterprise Non Gallery Application.
3. Go to Enterprise Applications -> Newly Created App -> Single sign-on.
4. Enable SAML, using the following details:
   1. Identifier (Entity ID): urn:amazon:cognito:sp:xxx (replace xxx with cognito user pool id).
   2. Reply URL: (replace xxx with cognito domain)
      https://xxx.auth.ap-southeast-1.amazoncognito.com/saml2/idpresponse
5. Verify and re-map (if required) the following fields under, Single sign-on -> User Attributes & Claims -> Additional Claims
   • http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress -> user.userprincipalname
   • http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname -> user.givenname
   • http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name -> user.displayname
   • http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname -> user.surname
6. Download the Federation Metadata XML from the link under Single sign-on -> SAML Signing Certificate.

Integrating Azure AD with AWS Cognito

1. Go to Cognito user pool -> Federation -> Identity providers -> SAML -> upload the Federation Metadata XML downloaded in the previous step and create the provider.
2. Go to Federation -> Attribute mapping -> SAML and add the following mappings:
   • http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name -> Name
   • http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname -> Given Name
   • http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname -> Family Name
   • http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress -> Email
3. Go to App Integration -> App client settings, Enable newly added identity provider. Make sure under OAuth 2.0, Authorization code grant and Implicit grant are checked.
4. That’s it, now we move on to testing the new identity provider integration with Cognito.

Test integration

• Go to link: 
  https://<Cognito domain name>.auth.ap-southeast-1.amazoncognito.com/login?response_type=token&client_id=<Cognito App Client ID>&redirect_uri=<Cognito Callback URL>
• After successful login, you should be redirected to your application’s redirect URI configured in Cognito.

IMPORTANT:

• This flow can not be automated yet as Azure doesn’t support creating SAML based Applications through CLI, see issue.
• Azure Enterprise Applications do not support personal accounts for SSO, so you won’t be able to invite other domain users, including accounts like @live.com, @hotmail.com etc. See stackoverflow question.

Using OpenID Connect

Azure AD integration with Cognito using OIDC also consists of 2 parts, first we need to create an App Registration in Azure Active Directory and then we move on to integrating the newly created Azure AD application with our Cognito application.

Create Azure AD App Registration

1. Go to Azure portal -> Azure Active Directory -> App Registrations -> Register New Application.
2. On the creation page, fill out the form with desired values. 
3. Set the Redirect URI to (where xxx is the cognito domain)
   Web – https://xxx.auth.ap-southeast-1.amazoncognito.com/oauth2/idpresponse 
4. Create the App Registration and note Client ID.
5. Go to App Registration -> Your App -> Certificates and secrets -> Create new client secret and copy it.

Integrating Azure AD with Cognito

1. Go to Cognito user pool -> Your user pool -> Federation -> identity providers -> OpenID Connect.
2. Set the Provider name to a string that you want to be displayed on Frontend for this identity provider.
3. Paste the Client ID and secret obtained from Azure Active Directory App.
4. Set attributes request method to GET and Authorize score to: profile email openid
5. Set issuer to https://login.microsoftonline.com/tenant_id/v2.0, replace tenant_id with the tenant id of the Active directory which will issue the Oauth tokens i.e active directory containing users. For tenant_id of personal accounts check the note below.
6. Click Run Discovery and save the identity provider.
7. Now go to Federation -> Attribute mapping and set the following mappings:
   • name -> Name
   • preferred_username -> Preferred User Name
   • unique_name -> Given Name
   • email -> Email
   • sub -> Username
8. Test the Cognito integration by signing in using the Active directory account.
9. Go to Cognito user pool -> General settings -> Users and groups, find the user corresponding user entry to your previous sign in and verify the required attributes are being passed correctly.
10. Sometimes, depending upon the client’s active directory setup, the email field could be blank or missing, this is due to the missing contact information in the user account on the client’s end. If this is the case, we’ll have to find an alternate field which can be mapped for this attribute mapping:
    • email -> Email
11. If the email is blank or missing, look for an alternate field (in Users and groups values) which resembles an Email Id, depending upon the client’s active directory setup it could be preferred_username or sub or unique_name. Once you’ve figured it out, remap the field in Attribute Mappings of the OIDC to:
    • preferred_username -> Email (If preferred_username is the field which resembles email)
12. Test again.

Note:

If the article helped you, check out some other articles Basic commands for text manipulation in Linux, Create your own Minecraft Server using Azure Cloud, GeForce Now in India 2020.