Documentation
Documentation
Register Your SAML App
Register your application as a SAML 2.0 Service Provider (SP) so IdenX can issue signed assertions to it. Registration also provisions the OAuth credentials your app uses to exchange those assertions for tokens in Steps 2–5.
Go to: Register Your App → SAML App tab
Point your SP at IdenX
IdenX is the SAML Identity Provider. Configure your Service Provider with its two endpoints, shown at the top of the SAML App tab:
| Endpoint | URL |
|---|---|
| IdP Metadata | https://idp.xaa.dev/saml/metadata |
| IdP SSO (HTTP-POST + HTTP-Redirect) | https://idp.xaa.dev/saml/sso |
Most SP software can consume the metadata URL directly and configure itself. After you register, IdenX also exposes a per-app metadata URL (https://idp.xaa.dev/saml/app/{id}/metadata) scoped to your registration.
Identity prompt
The first time you visit, you're asked for an email address. There is no account and no password. It is a namespacing key: every SAML app you register is scoped to this email, and your list is only visible when you return with the same address.
Registration form
Click + Register SAML App to open the form.
App Name (required)
A human-readable label shown in your app list and in IdenX system logs.
SP Entity ID (required)
Your Service Provider's entityID, usually a URL or URN (e.g. https://myapp.example.com/saml/metadata). This is the primary key for your registration and cannot be changed after registration.
Assertion Consumer Service (ACS) URL (required)
Where IdenX POSTs the SAML assertion after a successful login. Must be https:// (or http://localhost for local testing).
Single Logout (SLO) URL (optional)
Where IdenX sends LogoutResponse messages. Same URL rules as the ACS URL.
SP Metadata URL (optional)
If reachable, IdenX fetches it on save and auto-populates the SP's signing certificate.
SP Certificate (PEM) (optional)
Paste the SP's signing/encryption certificate. When present, IdenX can encrypt the assertion to your SP.
NameID Format
How IdenX identifies the user in the assertion. This value flows all the way through to the ID-JAG's sub_id.nameid_format.
| Format | NameID value | Use when |
|---|---|---|
| Email Address (default) | The user's email | The resource identifies users by email |
| Persistent | A stable pseudonymous hash of issuer:email | You need a durable ID without exposing the email |
| Transient | A random value, new every session | You never need to correlate the user across sessions |
A Transient NameID is different on every login, so the Resource Server sees a brand-new user each session. Only pick it if that's genuinely what you want. Choose Email Address or Persistent if the resource needs to recognize a returning user.
Attribute Mapping (optional)
Add rows mapping an IdenX user property to the SAML attribute name your SP expects. Properties available: email, firstName, lastName, name, groups. Blank rows are skipped.
Resource Connections (optional, up to 5)
Select a resource and the scopes your app needs. This is where the SAML app becomes an XAA client: adding a connection makes IdenX auto-provision a bound token-exchange client and issue the credentials for Steps 2–5.
A connection is an IdP-enforced policy: this app may request ID-JAGs targeting this resource with these scopes, and nothing else. A Step 3 request for any other resource or scope is rejected with invalid_target or invalid_scope.
The dropdown lists built-in resources plus any you've registered yourself. To add your own, register a resource app first.
What registration creates
Submitting the form shows a SAML app registered modal with everything you need.
Always shown:
| Value | Purpose |
|---|---|
| SP Entity ID | Confirms your registration's key |
| App Metadata URL | https://idp.xaa.dev/saml/app/{id}/metadata (per-app IdP metadata) |
| IdP SSO URL | Where your SP sends the SAMLRequest (Step 1) |
Shown when you added a resource connection. These are the two OAuth clients that drive the XAA flow:
IdP client (Steps 2 & 3)
Authenticates your app at the IdP's /token endpoint for both token exchanges.
| Credential | Used in |
|---|---|
client_id (Client ID at IdP) | Assertion → Refresh Token (Step 2), Refresh Token → ID-JAG (Step 3) |
client_secret (Client Secret at IdP) | Client authentication in Steps 2 and 3 |
Resource client (Step 4)
Automatically provisioned at the Authorization Server, one per connected resource.
| Credential | Used in |
|---|---|
client_id_at_resource | Client authentication in the JWT Bearer grant (Step 4) |
client_secret_at_resource | Client authentication in the JWT Bearer grant (Step 4) |
Just like the OIDC flow, the SAML path crosses a trust boundary at the JWT Bearer grant: the IdP client authenticates the token exchanges, and a separate resource client authenticates at the resource's Authorization Server. Using the IdP client at Step 4 returns invalid_client.
The auto-provisioned IdP client uses client_secret_post: credentials go in the POST body, not in an Authorization: Basic header.
Managing your app
Your registered SAML apps appear in the list below the form. On each card you can reveal the IdP client secret, open the Integration Guide, edit non-key fields (everything except the SP Entity ID), add or remove resource connections, and delete the app. Deleting an app also removes its auto-provisioned clients.
Next step
Once your SP is configured with the IdenX metadata and you have your credentials, proceed to Step 1: SAML SSO.
On this page