Skip to main content
Use fresh AWS accounts

Install AlphaAgent Organisations into a new, empty AWS account, and give every AlphaAgent Studio deployment a new, empty AWS account of its own. Three reasons:

  1. It is AWS best practice to isolate each workload in its own account, with its own limits, billing view and permissions.
  2. Amazon Bedrock quotas are set per AWS account. Many users in one deployment share one quota and exhaust it; one account per deployment keeps each team's capacity its own.
  3. The blast radius is smaller. A problem in one deployment, or one team's mistake, cannot reach the others.

Connect your Entra ID tenant for Studio sign-in (SSO)

For the console owner or operator (or IdentityProviderManager) with an Entra ID administrator who can create an app registration and grant tenant-wide admin consent. The person who clicks Connect must be signed in to the console (owner, operator or IdentityProviderManager) and be able to grant tenant-wide consent in Microsoft (a Global Administrator); if your Global Administrator is not the break-glass owner, grant them a console role first on Identity & Access Management > Users (Users, groups and roles). No Studio deployment can be launched until a tenant is connected. This is the second Entra ID set-up and a different Entra object from the SAML application on the previous page: that one signs your administrators in; this one lets the Organisation create each Studio deployment's own enterprise application for single sign-on (SSO) and assign users to it.

1. Open Identity Providers​

In the console open Identity Providers ("Connect your identity provider once, then use it for single sign-on across any of your Studio deployments."). On a new install the empty state reads "No identity providers connected yet". Click Connect identity provider (disabled tooltip: "Requires the IdentityProviderManager role (or owner/operator)"). The Connect an identity provider page opens with an Instructions card and an Identity Provider Configuration card.

2. Create the app registration in Entra​

Your Entra administrator follows the Instructions card:

  1. entra.microsoft.com (or portal.azure.com > Microsoft Entra ID) > App registrations > New registration. Name it, for example "AlphaAgent Organisations - Identity Provider Integration".
  2. Supported account types: Accounts in any organizational directory (Any Microsoft Entra ID tenant - Multitenant) (a dropdown, not radios). Under it Entra pre-checks "Select to allow only specific tenants", which disables Register: choose Allow all tenants. Redirect URI: platform Web, value copied from the card, your console origin plus /org-api/identity-providers/callback (for example https://org.example.com/org-api/identity-providers/callback). Click Register.
  3. Copy the Application (client) ID from the Overview page.
  4. API permissions > Add a permission > Microsoft Graph > Application permissions (not Delegated; the groups are collapsed, tick the checkbox rather than the row): Application.ReadWrite.OwnedBy, Application.Read.All, User.Read.All, Group.Read.All, AppRoleAssignment.ReadWrite.All. Click Grant admin consent; the status column flips to granted. A publisher-verification banner may show and does not block.
  5. Certificates & secrets > New client secret: any description, an expiry (default 180 days, maximum 24 months) > Add > copy the Value at once; it stays visible only until the page reloads.

Every Microsoft Graph call Organisations makes runs as the application itself (app-only), with these five permissions:

Permission (Application)What Organisations uses it for
Application.ReadWrite.OwnedByCreates each deployment's Enterprise Application from Microsoft's non-gallery template, as its owner, and sets its SAML identifier, reply URL, claims and signing certificate. It can change only applications it created.
Application.Read.AllReads those applications back while they are set up; finds the console's own Enterprise Application; reads which people and groups are assigned to an application before assigning more; reads the client secret's expiry for Credentials.
User.Read.AllSearches your directory for people (Users, the principal picker, Library members) and resolves a person by email or user principal name when you grant StudioUser or a console role; reads the names and emails of group members.
Group.Read.AllSearches your directory for groups, and reads the members of every group you grant a role to, for group sync and seat counts.
AppRoleAssignment.ReadWrite.AllAssigns people and groups to a deployment's Enterprise Application when you grant StudioUser, and console-role holders to the console's own Enterprise Application; removes those assignments on a revoke.
  • Entra adds the delegated User.Read to every new registration. Organisations never uses it: you may remove it before Grant admin consent, and the consent page then lists five permissions.
  • The tenant's display name is read with GET /organization, which Microsoft documents under Organization.Read.All. That permission is not needed: if the read is refused, the tenant connects with its ID as its name.
  • Group membership is read from the group's direct members. Members of nested groups are not resolved, and groups with hidden membership would need Member.Read.Hidden, which Organisations does not ask for.

3. Enter the credential and connect​

In Identity Provider Configuration: Provider type Microsoft Entra ID (the only choice); Client ID, the GUID (anything else: "That does not look like a Client ID -- it should be a GUID"); Client secret, the Value (Reveal to check the paste; spaces or line breaks are refused, usually browser autofill). Click Connect ("Saving...", then "Redirecting to Microsoft..."). Microsoft's consent page lists six permissions (the five plus the default delegated User.Read, or five if you removed it) and may carry an "unverified publisher" banner; accept as an administrator who can grant tenant-wide consent. You return to the new provider's page.

What you should see​

The provider page: Tenant name, Tenant ID, Status "Connected", Connected date, Deployments 0; a Connection section with Delete; Credentials with the Client ID (last four characters), Expires ("from Microsoft" or "entered by hand", with days remaining) and Update credentials. The list has a row Tenant, Type "Microsoft Entra ID", Status, Connected. The deploy wizard's Identity provider section now offers "<tenant name> (Microsoft Entra ID)".

Notes​

  • One app registration and one secret serve every tenant you connect. From 30 days before expiry the row reads "Secret expires in N days"; after it, "Secret expired", and provisioning, directory search and assignments fail until updated. Rotate with Update credentials (Client ID, new Client secret, optional Secret expiry; "Verified with Microsoft and saved." or "Saved. Not verified yet" when no tenant is connected). Requires owner or operator (or IdentityProviderManager).
  • A single-tenant registration cannot be consented to from the console's flow. A connect attempt is valid for 15 minutes.
  • Delete removes only the Organisation's record, not the enterprise applications Microsoft created in your tenant; a provider linked to deployments cannot be deleted.
  • A deployment's Identity view can show SAML service-provider values for a deployment with no tenant linked, but the wizard offers no manual SAML path: Deployment detail.
  • Consent errors return you to the list with a message: Troubleshooting the install.