SP account mapper
Use the SP account mapper to customize how SAML 2.0 assertions are mapped to user profiles.
- Script bindings
Example scripted SP account mapper
This section describes how to implement an example SP account mapper that uses a script to auto-federate user accounts. It assumes that you have configured your environment for single sign-on using SAML 2.0, where Advanced Identity Cloud is the hosted SP. These example steps use a separate Advanced Identity Cloud tenant as the remote IdP.
Prepare the user profiles
-
Create a test user on the hosted SP, for example
bjensen, with an email address set tobjensen@example.com. -
Create a test user on the hosted IdP, for example
babsjensen, with an email address also set tobjensen@example.com.
Configure auto-federation
Under Native Consoles > Access Management, go to Applications > Federation > Entity Providers and click on the name of the hosted provider.
-
On the tenant configured as the hosted SP:
-
Under Assertion Processing > Auto Federation:
-
Switch on Enabled.
-
Set Attribute to
mail.
-
-
Save your changes.
-
-
On the tenant configured as the hosted IdP:
-
Under Assertion Processing > Attribute Mapper, add the following Attribute Map:
- Name Format Uri
-
urn:oasis:names:tc:SAML:2.0:attrname-format:basic - SAML Attribute
-
mail - Local Attribute
-
mail
-
Save your changes.
-
Update the SP account mapper script
-
Under Native Consoles > Access Management, go to Scripts, and click SAML2 SP Account Mapper Script.
-
Update the script to implement any custom behavior for auto-federation. This example adds a logging statement to record the assertion map.
... userID = accountMapperHelper.getAutoFedUser(nameID["value"]); if (userID != null && userID.length > 0) { // // insert custom code here // // update logging to output assertion and userID logger.error("Assertion: " + assertion); logger.error(debugMethod + " use AutoFedUser as userID: " + userID); return userID; } else { ... }Learn about the available bindings in the SP account mapper scripting API. -
Still in the native console, go to Applications > Federation > Entity Providers > Hosted SP Name > Assertion Processing.
-
Under Account Mapper, select
SAML2 SP Account Mapper Scriptfrom the Account Mapper Script list. -
Save your changes.
Try the script
-
To verify the script works as expected, test your changes using an SP-initiated flow.
For example:
https://<tenant-env-sp-fqdn>/am/saml2/jsp/spSSOInit.jsp?realm=/alpha&idpEntityID=idp1&metaAlias=/alpha/sp1&binding=urn%3Aoasis%3Anames%3Atc%3ASAML%3A2.0%3Abindings%3AHTTP-POST -
Log into the IdP as
babsjensen.After you’ve logged into the IdP successfully, you shouldn’t need to log into the SP because the script auto-federates the
babsjensenandbjensenaccounts. -
Verify that
bjensenis logged into the SP.You can also check that the SP debug logs contain the customized logging output, for example:
Assertion: { "version": "2.0", "issueInstant": 1758805815000, "subject": { "subjectConfirmation": [ { … } ScriptedSPAccountMapper.getIdentity:: use AutoFedUser as userID: id=bjensen,ou=user,o=alpha,ou=services,ou=am-config
SP account mapper scripting API
The following bindings are available to SP account mapper scripts.
| The SP account mapper script is a next-generation script and therefore has access to all the next-generation common bindings in addition to those described here. |
| Binding | Description |
|---|---|
|
The helper object contains supporting methods that provide context information when customizing account mapping on the SP.
|
|
The SAML 2.0 assertion as a map of values. Example assertion map
|
|
The entity ID for the hosted SP. |