Handoff · Azure Admin

PayCargo Foundation — Azure Entra SAML SSO Setup

Enterprise Application configuration for the AI-Sandbox Cognito user pool

1Purpose

We are federating sign-in for the PayCargo AI Platform (AI-Sandbox environment) to Azure Entra so PayCargo employees use their PayCargo identity, keep their MFA setup, and stop needing a separate Cognito password. This is a one-time setup on your side. Once complete, adding a user to the platform is just adding them to the assigned Azure group.

Our side is fully staged: the platform Console has a Setup wizard that applies your SAML metadata URL to the Cognito user pool the moment we paste it in. When you return the URL, Sign In With Azure goes live within seconds — no infrastructure deploy on our end.

2Two values from our side

Configure the Azure Enterprise Application with these exact strings. Do not add or trim characters.

Reply URL (ACS) https://ai-sandbox-obs-app-75397437.auth.us-east-1.amazoncognito.com/saml2/idpresponse
Identifier (Entity ID) urn:amazon:cognito:sp:us-east-1_xA2gIdfwa

The Reply URL is where Azure will POST the SAML assertion. The Identifier is the Cognito service-provider entity ID Azure needs to recognize as the audience of the assertion.

3Steps in the Azure Entra admin center

  1. In Microsoft Entra admin center, open Identity › Applications › Enterprise applications and click New application.
  2. Choose Create your own application. Name: PayCargo AI Platform (AI-Sandbox). Select Integrate any other application you don't find in the gallery (Non-gallery).
  3. Open the new app. In the left rail, click Single sign-on, then choose SAML.
  4. In Basic SAML Configuration, enter the two values from Section 2. Save.
  5. In Attributes & Claims, configure the claims per Section 4 below. Delete the default extra claims so only email and name are emitted.
  6. In SAML Certificates, copy the App Federation Metadata URL. This is the value you send back to us (Section 5).
  7. In Users and groups, assign the pilot users or groups who should be able to sign in. Recommend a small pilot group first, then a broader group after Section 6 is verified.
  8. Apply a Conditional Access policy requiring MFA on this app. See Section 6.

4SAML attribute claims

Cognito is configured to read exactly two SAML attributes. Delete any additional default claims that Entra emits (Given Name, Surname, etc.) unless you want them logged; they will not be consumed.

Cognito attributeSAML claim URISource in Azure
email http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress user.mail
name http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name user.displayname

If your naming convention uses user.userprincipalname instead of user.mail for the email claim, that is fine as long as it is a valid, unique email format.

5What to send back to us

One value: the App Federation Metadata URL from Section 3 step 6. It looks like:

https://login.microsoftonline.com/<tenant-id>/federationmetadata/2007-06/federationmetadata.xml?appid=<app-id>

Reply to Mike Tang (mtang@paycargo.com) with this URL. Mike pastes it into the Console's Setup wizard and clicks Apply — Sign in with Azure goes live within seconds. We confirm end-to-end sign-in with one pilot user the same day.

6MFA and Conditional Access

Cognito trusts Azure's authentication assertion, which means our MFA posture inherits directly from your Conditional Access policy on this app. The Forge doctrine assumes MFA is enforced upstream at Azure, not duplicated at Cognito.

Baseline policy:

7What happens next

  1. You send us the metadata URL.
  2. Mike pastes it into the Console's Setup wizard (Setup › Integrations › Azure Entra SAML SSO) and clicks Apply. It takes effect in seconds; no infrastructure deploy.
  3. A pilot user in the assigned group visits app.paycargo.ai (until that address is live: d3m6zyvaoy8jck.cloudfront.net). A Sign in with Azure button appears. They click it, authenticate at Entra, and land in the Console.
  4. The user shows up in Cognito with zero group memberships. They open the Request Roles cartridge, ask for what they need, an operator approves. Their group memberships are set inside our platform, not in Azure.
This is intentional. Azure owns who a person is. The platform owns what they can access.

8Contact

Questions or edge cases: Mike Tang, mtang@paycargo.com.

This handoff document mirrors the process used for the Salesforce Connected App handoff (Step 6.n in the platform documentation). If you handled that, this is the same shape, different vendor.