Skip to main content
Submit a Request

Troubleshooting: SecureAuth CIAM External Identity Provider Sign-In or Just-in-Time Provisioning Fails

Ben Watts
Updated
    Applies to:
  • CloudEntity
    Deployment model:
  • Cloud

Version Affected: All
 
 

Overview

Sign-in through an external SAML or OpenID Connect (OIDC) identity provider (IdP) fails in SecureAuth CIAM. In other cases the user signs in, but Just-in-Time (JIT) provisioning fails, creates a duplicate user, or leaves attributes empty. The user usually sees a generic error page, such as Request Unauthorized, cannot log in with identity provider, Server Error or Invalid Request.

The cause shows in two places: the workspace's audit logs, filtered by the connection's ID, and the detailed error in the SecureAuth CIAM service logs, which SecureAuth Support can search by the trace ID or authorization correlation ID shown on the error page. Find the error or behavior you see in the list below; each entry links to its cause. The causes are not related, so a fix for one cause will not resolve another.

 

In this article


 

Cause 1: Attributes Are Not Mapped Into the Authentication Context

The authentication context is the set of user attributes that SecureAuth CIAM builds for each sign-in. Tokens, JIT provisioning and policies read only from it, not from the raw SAML assertion or ID token. An attribute the IdP sends reaches the authentication context only when it is listed on the connection's Attributes tab and mapped to an authentication context attribute. A value that is in the assertion but not mapped is ignored.

JIT provisioning needs an identifier, such as the email address, to create or match the user. When none is mapped, provisioning fails with at least one user identifier must be configured. When no email address is mapped, an administrator who signs in to the admin portal through the connection is shown as Profile.

 

Resolution 1:

To resolve this:

  1. Go to Authentication > Providers, open the connection, and open the Attributes tab. Confirm that each attribute is listed with exactly the name the IdP sends. If one is missing, click Add attribute; the list accepts any name.
  2. If the authentication context has no attribute to receive the value, go to Authentication > Settings > Attributes and create one.
  3. Select Mappings, map each source attribute to its authentication context attribute, and click Save mappings.
  4. Open the Provisioning tab and confirm that Identifier Correlation and the attribute rows use the authentication context attributes you just mapped, including the email address.
  5. Sign in again and confirm that the login_accepted audit event shows every mapping as "result": "mapped".

 

Cause 2: The Mapping Source Does Not Match What the IdP Sends

SecureAuth CIAM looks up each mapping's source attribute by its exact name. Every successful IdP sign-in writes a login_accepted audit event, and its idp_mapping_details list shows each mapping with "result": "mapped" or "result": "missing". A mapping is missing when:

  • The name differs from what the IdP sends, for example a source of mail when the IdP sends email.
  • The name carries a hidden character, such as a trailing tab copied in with it.
  • The SAML attribute name contains dots and they were escaped by hand. The current SAML connector, shown as saml_v2 in audit logs, escapes dots itself, so a dot with a typed backslash is escaped a second time.

When the identifier attribute is missing, JIT provisioning cannot match the sign-in to the existing user. It creates another user with no identifiers each time, and applications that rely on the identifier report a sign-in failure.

 

Resolution 2:

To resolve this:

  1. Capture the attribute names the IdP actually sends, by using a SAML tracer browser extension for a SAML assertion, or by decoding the ID token for OIDC.
  2. In the workspace's Audit Logs, filter by the connection's ID, open the login_accepted event, and note every source attribute marked missing.
  3. Go to Authentication > Providers, open the connection, and correct each of those attributes on the Attributes tab and in Mappings. Type the name rather than pasting it, so that no hidden character is carried in, and remove any backslashes before dots in a SAML attribute name.
  4. Save, sign in again, and confirm that every mapping now shows mapped.
  5. Delete any duplicate users that JIT provisioning created with no identifiers.

 

Cause 3: A Required Identity Pool Attribute Is Missing

An identity pool's schema can mark attributes as required, for example first name and last name. JIT provisioning cannot create a user without them, so the sign-in ends with:

Invalid Request failed to provision user

Usually the external IdP does not send the attribute for that user, or the attribute is not mapped.

Do not turn JIT provisioning off to get past this error. An extension script that reads the provisioned user then fails instead, with an error such as Cannot read properties of undefined (reading 'business_metadata'), and the user sees Server Error.

 

Resolution 3:

To resolve this:

  1. Check which attributes the identity pool's schema marks as required.
  2. Go to Authentication > Providers, open the connection, and confirm on the Provisioning tab that each required attribute has a row whose source is a mapped authentication context attribute.
  3. At the external IdP, confirm that the application releases those attributes and that the user has values for them. For example, check the attribute mapping on the SAML application in Google Workspace.
  4. Where a value may legitimately be absent, click Set default value on the row to give it a fallback.

 

Cause 4: The Attribute's Data Type Does Not Match the Incoming Value

Every mapping has a data type, and the incoming value must match it. If the authentication context or identity pool attribute is a string array but the IdP sends a single string, the sign-in fails with an error such as:

failed to remap authentication context: Error(400, Could not parse attributes, failed to decode string_array from <value>: '': source data must be an array or slice, got string

The same error appears when the assertion contains the same attribute twice, once with several values and once with a single value.

 

Resolution 4:

To resolve this:

  1. Capture the assertion and check how many times the attribute appears and how many values it carries.
  2. If the IdP sends the attribute more than once, correct it at the IdP so that it is sent once.
  3. Set the same data type on the connection's Attributes tab, the authentication context attribute, and the JIT provisioning target, matching what the IdP sends: a string for a single value.
  4. For a business metadata target, use business_metadata.<attribute>, not user.business_metadata.<attribute>.

 

Cause 5: User Record Lookup on Another Connection Selects the Wrong Identity Pool

Intelligent Discovery decides which connection handles a sign-in. When a connection has User record lookup turned on, SecureAuth CIAM checks whether the identifier exists in that connection's identity pool and, if it does, sends the sign-in there. This takes priority over email domain matching, and it applies even when that connection is disabled or sits in the parent workspace.

As a result, a user who also exists in another identity pool is sent to the wrong one. A password sign-in fails with authentication failed, and the failed audit event shows an unexpected identity_pool_id. A federated sign-in ends in Server Error and no user is created. Promoting configuration from one environment to another can switch User record lookup on or off without anyone noticing.

 

Resolution 5:

To resolve this:

  1. In the workspace's Audit Logs, open the failed sign-in event and note its identity_pool_id.
  2. Go to Authentication > Providers in the workspace and in its parent workspace, and check every connection, including disabled ones, for User record lookup under User record based discovery.
  3. Clear User record lookup on any connection that should not claim these users, or remove the duplicate user from the other identity pool.
  4. After every configuration promotion between environments, check User record lookup on each connection again.

 

Cause 6: The IdP Rejects SecureAuth CIAM's Client Credentials

For an OIDC connection, Microsoft Entra ID included, SecureAuth CIAM exchanges the authorization code at the IdP's token endpoint using the connection's client ID and client secret. If the IdP rejects them, the user sees Request Unauthorized, and the service logs show idp_unable_to_login with an error such as:

failed to exchange code: microsoft: failed to get token: oauth2: cannot fetch token: 401 Unauthorized
Response: {"error":"invalid_client","error_description":"AADSTS7000222: The provided client secret keys for app '<app-id>' are expired.

The IdP's error code identifies the problem:

  • AADSTS7000222: the client secret has expired.
  • AADSTS7000215: the secret's ID was entered instead of the secret's value.
  • cannot fetch token: 403 Forbidden followed by the IdP's own error page: the IdP refused the request, most often because of a wrong client secret.

 

Resolution 6:

To resolve this:

  1. Check the IdP's own sign-in logs for the error, or ask SecureAuth Support for the error recorded in the SecureAuth CIAM service logs.
  2. At the IdP, create a new client secret and copy its value. For Microsoft Entra ID, copy the Value, not the Secret ID.
  3. Go to Authentication > Providers, open the connection, enter the new client secret, and click Save.
  4. Record the new secret's expiry date and replace it before it expires.
  5. If you update the connection with the Admin API, include the client ID and the client secret in the request. Without them, the API returns 422 ClientID is a required field, ClientSecret is a required field.

 

Cause 7: The IdP's Issuer Does Not Match the Configured Issuer URL

SecureAuth CIAM reads the IdP's discovery document at <issuer>/.well-known/openid-configuration. Both the issuer in that document and the iss in each ID token must exactly match the connection's Issuer URL. If the IdP returns a different issuer, for example a staging or beta host, sign-in fails with errors such as:

failed to get provider configuration from https://<idp-host>/.well-known/openid-configuration: oidc: issuer did not match the issuer returned by provider, expected "https://<configured-issuer>" got "https://<other-issuer>"
oidc: failed to verify ID Token: oidc: id token issued by a different provider

When only some of the IdP's servers return the wrong issuer, the failures are intermittent.

 

Resolution 7:

To resolve this:

  1. Open the IdP's discovery URL in a browser and compare its issuer value with the connection's Issuer URL.
  2. If the IdP has changed its issuer permanently, go to Authentication > Providers, open the connection, and set the Issuer URL to the new bare issuer, without /.well-known/openid-configuration.
  3. If the IdP returns different issuers at different times, raise the issue with the IdP's vendor, because the fault is on the IdP's side.

 

Cause 8: The SAML IdP Rejects the NameID Policy

The SAML IdP answers the authentication request with an error status instead of an assertion, so the user sees cannot log in with identity provider. The SecureAuth CIAM service logs show status code of the Response was not Success, was "Requester", and a SAML tracer shows:

<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Requester">
  <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:InvalidNameIDPolicy" /></samlp:StatusCode>

The IdP could not issue a NameID in the format the request asked for, for example an email-address NameID for a user with no email address. Active Directory Federation Services (AD FS) logs this as MSIS7070: The SAML request contained a NameIDPolicy that was not satisfied by the issued token.

 

Resolution 8:

To resolve this:

  1. Capture the SAML response with a SAML tracer browser extension and confirm the status codes above.
  2. Check the IdP's own log for the requested NameID format. For AD FS, look for MSIS7070 in the AD FS Admin event log.
  3. At the IdP, issue a NameID in the requested format for every user, for example with an AD FS claim rule that sends the email address as a NameID in Email format.
  4. Make sure the users have a value in the attribute the NameID is built from.

 

Cause 9: The Sign-In Did Not Start at SecureAuth CIAM

A SAML sign-in has to start at SecureAuth CIAM. Before it sends the user to the IdP, SecureAuth CIAM sets a session cookie that ties the returning response to the sign-in. If the IdP posts a response to the workspace's login URL when no sign-in was started, for example from a bookmark of that URL or an IdP-initiated sign-in, SecureAuth CIAM has no session to match it to and returns 404 tenant not found.

 

Resolution 9:

To resolve this:

  1. Start the sign-in from the application, or from the organization's portal URL, which ends in /<organization>/b2b, not from its login URL, which ends in /<organization>/login.
  2. Update any bookmarks or IdP application tiles so that they open that start URL.
  3. If the error continues when the sign-in starts at SecureAuth CIAM, use the browser's developer tools to confirm that the SecureAuth CIAM session cookies are still present when the IdP returns the user.

 

SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.

Comments

0 comments

Please sign in to leave a comment.