Setting up single sign-on (SSO) via Microsoft AD FS – AEB Help Center

To enable single sign-on via Microsoft AD FS, set it up via Active Directory Federated Services (AD FS) in the AD FS management console.

You are responsible for your own connection. AEB does have standard documentation available offering several examples, however. Please reach out to your AEB representative for assistance.

1. Configuring Relying Party Trust

To configure the Relying Party Trust, you must be an administrator or an administrative user with extended rights.

Open AD FS management console − Relying Party Trusts.
In the Actions pane on the right, under Add Relying Party Trust, select Claims aware.
Click Start to confirm.
Enter the Federation metadata address provided by AEB. For example: https://test.idp.aeb.com/auth/realms/aeb/broker/<example>/endpoint/descriptor.
Click Next.
Select a display name.
Under Steps, go to Access Control Policy to define which users/groups can log in to the application and whether additional security factors such as MFA are required.
Click Next/Finish to complete the configuration process.

Claims are used to determine the attributes that the IdP transmits to AEB’s IAM. During logins, these attributes are expected in the token.

The unique attribute must be sent in the form of an email address (<value>@<domain>) and differs depending on whether OpenID Connect or SAML is used.
For the extended attributes of the users, the Friendly Name is the same for both OpenID Connect and SAML.

Attributes already set

The following attributes are defined as unique attributes:

Attribute	Description	Value	Format
OpenID Connect‒preferred_username:	Unique value of user – with Microsoft, for example, the User Principal Name	Jane.Doe@domain.com	<String>
SAML‒nameID:	Unique value, such as policy format email	Jane.Doe@domain.com	<String>

The following attributes are defined as extended attributes:

Attribute	Description	Value	Format
given_name	First name of user	Jane	<String>
family_name	Last name of user	Doe	<String>
email	Email address or another attribute, including the domain <value>@<domain>	Jane.Doe@domain.com	<String>

The following attribute defines the role:

Attribute	Description	Possible values
roles	Roles of the user, usually in the form of an ArrayList.	clientAdmin

The following attribute is optional:

Attribute	Description	Value	Format
alternative_username	Alternative user name that can be used in applications	M12345	<String>

Creating rules for the claims

You need to create two rules for the claims:

Rule 1

Select the new Relying Party Trust. In the menu on the right, select Edit Claim Issuance Policy.
Under Issuance Transform Rules, click Add Rule.
Select the template Transform an Incoming Claim.
Specify a name and adjust the values accordingly so that the User Principal Name or an alternate attribute is sent as the Name ID.
Click Finish to close.

If an alternate attribute is used, it must be sent in the format of an email address: <attribute>@<domain>.

Rule 2

Select the new Relying Party Trust. In the menu on the right, select Edit Claim Issuance Policy.
Under Issuance Transform Rules, click Add Rule.
Select the template Send LDAP Attributes as Claims.
Enter a name, select the value Active Directory as Attribute store, and create a mapping for the attributes E-Mail Address, Surname and Given-Name.
Click Finish to close.

Select the new Relying Party Trust. In the menu on the right, select Edit Claim Issuance Policy.
Create a new rule and a corresponding mapping for each group.
Click Finish to close.