This section explains how to configure an application through AD FS 2.0 that gets federated access to an application by using Access Manager. The setup uses the SAML 2.0 POST profile.
The AD FS metadata is used to add an Identity Provider to Access Manager.
Access the AD FS server metadata by going to https://<<ADFS hostname or IP/FederationMetadata/2007-06/FederationMetadata.xml
Save the AD FS metadata data.
Open the AD FS metadata file in Notepad, WordPad, or an XML editor).
Remove the <RoleDescriptor> tags from the metadata.
For example, remove the following tags:
"<RoleDescriptor xsi:type="fed:ApplicationServiceType"
protocolSupportEnumeration=http://..................... ……> ……….</RoleDescriptor>
"<RoleDescriptor xsi:type="fed:SecurityTokenServiceType"
protocolSupportEnumeration=http://..... ………> </RoleDescriptor>
Save the changes.
In the Access Manager Administration Console, select Devices > Identity Server.
Click Edit.
Select SAML 2.0.
Click New > Identity Provider.
Specify the name as ADFS in the Name field.
Select Metadata Text from the Source list.
Paste the copied ADFS metadata that you saved in Step 5 into the Text field.
Click Next.
Specify an alphanumeric value that identifies the card in the ID field.
Specify the image to be displayed on the card in the Image field.
Update the Identity Server.
Retrieve the AD FS server's CA trusted root certificate.
In the Access Manager Administration Console, select Security > Certificates.
Select Trusted Roots.
Click Import.
Specify the certificate name, and browse for the AD FS certificate authority.
Click OK.
Click uploaded AD FS CA.
Click Add to Trusted Store and select config store.
Update the Identity Server.
Select the AD FS Identity Provider in the SAML 2.0 tab.
Click Authentication Card > Authentication Request.
Select Response Protocol Binding to POST.
Select NAME Identifier Format as Transient.
Click OK.
Update the Identity Server.
The metadata import capability of AD FS 2.0 is used to create a relying party. The metadata includes the public key that is used to validate security tokens signed by Access Manager.
In AD FS 2.0, right-click the Relying Party Trusts folder, then click Add Relying Party Trust to start the Add Relying Party Trust Wizard.
Click Start.
On the Select Data Source page, select Import data about the claims provider from a file.
In the Federation metadata file location section, click Browse.
Navigate to the location where you saved nam_metadata.xml earlier, select the file, then click Open > Next.
On the Specify Display Name page, specify NAM Example.
Click Next > Next > Close.
The data from AD FS is used in the security token that is sent to Access Manager.
The Edit Claim Rules dialog box should already be open. If not, in the AD FS 2.0 center pane, under Relying Party Trusts, right-click NAM Example, then clickEdit Claim Rules.
On the Issuance Transform Rules tab, click Add Rule.
On the Select Rule Template page, leave the Send LDAP Attributes as Claims option selected, then click Next.
On the Configure Claim Rule page, specify Get attributes in the Claim rule name field.
Select Active Directory from the Attribute Store list.
In the Mapping of LDAP attributes section, create the following mappings:
|
LDAP Attribute |
Outgoing Claim Type |
|---|---|
|
User-Principal-Name |
UPN |
|
E-Mail-Address |
E-Mail Address |
Click OK.
Click Apply > OK.
On the Insurance Transform Rules tab, click Add Rules.
On the Select Rule Template page, select Transform an Incoming Claim, then click Next.
On the Configure Claim Rule page, use the following values:
|
Name |
Value |
|---|---|
|
Claim rule name |
Mapping To Transient Name Identifier |
|
Incoming Claim Type |
UPN |
|
Outgoing Claim Type |
Name ID |
|
Outgoing name ID format |
Transient Identifier |
Select Pass Through All Claims, then click OK.
Click Apply > OK.
By default, Access Manager uses the Secure Hash Algorithm 1 (SHA-1) for signing operations. By default, AD FS 2.0 expects partners to use SHA-256.
Perform the following steps to setup AD FS 2.0 to expect SHA-1 for interoperability with the Access Manager Identity Provider:
In AD FS 2.0, click Claims Provider Trusts > right-click Ping Example > Properties.
On the Advanced tab, select SHA-1 in the Secure Hash Algorithm list.
Click OK.
For more information about signing and encryption certificates, see Using Certificates and Certificate Revocation Lists.
Modify /opt/novell/nam/idp/conf/tomcat7.conf and add JAVA_OPTS="${JAVA_OPTS} -Dcom.novell.nidp.serverOCSPCRL=false"
Click Start > Administrative Tools > Windows PowerShell Modules.
Enter the following command at the PowerShell command prompt:
set-ADFSRelyingPartyTrust -TargetName "NAM Example"
-SigningCertificateRevocationCheck None
In AD FS 2.0, encryption of the outbound assertions is enabled by default. Assertion encryption occurs for any relying party or service provider for which AD FS 2.0 possesses an encryption certificate. AD FS 2.0 uses 256-bit Advanced Encryption Standard (AES) keys or AES-256 for encryption. In contrast, PingFederate supports a weaker algorithm (AES-128) by default. Failing to reconcile these conflicting defaults can result in the failed SSO attempts. To resolve this issue, disable the encryption in AD FS 2.0.
In AD FS 2.0, click Start > Administrative Tools > Windows PowerShell Modules.
Enter the following command in at the PowerShell command prompt:
set-ADFSRelyingPartyTrust -TargetName "NAM Example"
-EncryptClaims $False