Importing Service Provider metadata into the Identity Provider
The Service Provider metadata must be imported into the Identity Provider to complete the trust relationship between the Identity Provider and the ASM app.
To Import the Service Provider metadata, follow these steps:
On the Identity Provider Server (Server hosting your domain’s ADFS Server):
Open the Microsoft Management Centre (MMC)
Add the AD FS Management snap-in.
Click File > Add/Remove Snap-in .
Select AD FS Management from the list.
Click OK.
Expand the AD FS tree in the new snap-in.
Select Relying Party Trusts.
Right click the folder and select Add Relying Party Trust. The Add Relying Party Trust wizard will open.
Click Start.
Select the Import data about the relying party from a file option.
Click Browse.
Select the text file with the metadata you saved earlier.
Click Next
Enter a Display Name for the party trust.
Click Next
Select the I Do not want to configure multi-factor authentication settings for this relying party trust at this time option.
Click Next.
Select Permit all users to access this relying party option.
Click Next, and Next again on the Ready to Add Trust screen.
Click Finish
Claim Rules
Once you have completed the Add Relying Party Trust Wizard you will need to configure the rules for the relying party. To configure this:
Right Click on the Relying Party Trust you just created.
Select Edit Claim Rules.
Click Add Rule. The Add Transform Claim Rule Wizard will open.
Select Send LDAP Attributes as Claims as the Claim Rule Template.
Click Next.
Enter a relevant Claim Rule Name for the rule.
Select Active Directory under Attribute Store drop-down field.
Map the LDAP Attributes to Outgoing Claim Values.
Click OK, Apply and OK to complete the rule.
Right click on the Relying Party trust from the MMC snap-in and select Properties.
Select the Identifiers tab.
In the Relying Party Identifier field, enter/paste the Service Identifier string extracted from the ASM Service Provider Record.
Click Add.
Click Advanced tab.
Set the Secure Hash Algorithm to SHA-1 or SHA-256; whichever is selected in the Identity Provider details.
Click OK
Note on Claim Rules
The Single Sign On Connector does not read the LDAP Attributes directly, instead it reads the attributes received in the Inbound SAML Assertion. Name ID is a special SAML Assertion attribute which represents the User Name.
The Single Sign On Connector currently ships with mappings for User Name, First Name, Surname and Email Address by default. It is recommended that the Identity Provider Claims be configured for these ASM Single Sign On connector mappings
In ADFS, some special cases of the Inbound Claims are translated to similar looking Display Names. However, if you select the names using the drop-down then the actual Outbound Claim appears in the URL formal, which can cause confusion, the Single Sign On Connector therefore translates this back to a value that more closely resembles the display name:
Connector receives Email Address and not
SAML | ADFS LDAP Attribute Display | ADFS Outbound Claim Display * | ADFS Outbound Claim Actual | Converted To | ASM ICNF |
Name ID | Name ID | Name ID | Name ID | User Name | User Name |
First Name | Given-Name | Given Name | http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname | First Name | First Name |
Surname | Surname | Surname | http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname | Surname | Surname |
Email Address | E-Mail-Addresses | E-Mail Address | http://schemas.xmlsoap.org/claims/EmailAddress | Email Address | Email Address |
First Name | Given-Name | First Name | First Name | First Name |
*ADFS Outbound Claim Display is free text
For Azure, you must use the connector and set the matching rules to ensure that users do not have multiple usernames. This is configurable in the Premium version.
Person Import and Resource Mapping
The Single Sign-On Connector, in the same way as other ASM Directory Services connectors, can allow Person Records to be imported directly into ASM from the Identity Provider. The Person Records in ASM will then be kept up to date.
In order to use the Single Sign-On Connector an Integration Resource Mapping needs to be configured.
Recommended Field Mappings for Single Sign-On Connector Person Import
ASM | Connector Mapping | Identity Provider |
First Name | First Name | First Name |
Surname | Surname | Surname |
User Qualified Name | User Name | User Name |
NT Account Name | User Name | User Name (must be same as User Qualified Name) |
Login ID | User Name | User Name (must be unique) |
NT Domain Name | Must be blank | Must be blank |
All of the SAML based Identity Providers can be configured to send a variety of attributes with the SAML Security assertions, however it may not always be easily configurable through the respective user interfaces. For example the Active Directory Manager attribute is not exposed through the Microsoft ADFS User Interface.
Once the attributes have all been exposed by the Identity Provider the ASM Integration Platform and SSO Connector can easily consume these attributes and import/update Person Records as per other LDAP Connectors, however as this is time consuming and/or requires specific skills to configure the Identity Provider Claims then it may be a consideration to pre populate Users and Analysts using another method such as directly synchronising to an Active Directory Source, bulk import using a CSV file and the CSV Connector or by manual population initially.
It is also possible to configure SSO for a brand new system as long as the Username is mapped as above, however the accounts will only be created upon the initial login to ASM, therefore it is again recommended to pre populate the ASM System with Users and Analysts using another method such as directly synchronising to an Active Directory Source, bulk import using a CSV file and the CSV Connector or by manual population in order to have a useable system.
Once the Users and Analysts have been pre populated you can then use Resource Matching rules to match to and update the seeded database records with the Identify Provider using the SSO Connector.