archer implementing sso with adfs - community.rsa.com

Archer Implementing SSO with ADFS Contents Requirement: ................................................................................................................................................ 1

Section 1: Setting up ADFS as Service Provider (SP) ..................................................................................... 1

Setup Archer as an endpoint (relying party trust) .................................................................................... 1

Setup claim rules for the Archer endpoint ............................................................................................... 6

Section 2: Setup ADFS to communicate with various IDP - Internal domain. ............................................ 12

Section 3: Setup ADFS to communicate with various IDP - External domain. ............................................ 16

Section 4: Setup ADFS to communicate with various IDP – Microsoft Azure Active Directory. ................. 23

Section 5: Setup Archer SSO with Federation ............................................................................................. 35

This document highlight the configuration on ADFS and Archer for SSO implementation. The technology

used in the implementation is based on the SAML protocol

Requirement: Archer 6.2 or above

ADFS – Windows 2008 or above

(Optional) Other IDP that utilise SAML

Section 1: Setting up ADFS as Service Provider (SP) Archer can utilise ADFS as a service provider. The goal of service provider is to communicate with IDP

using SAML protocol for authentication. Once the user is authenticated by the IDP, SP will receive the

SAML token from IDP and send to Archer to consume. The following highlight the setup for ADFS as a SP

Setup Archer as an endpoint (relying party trust) 1. Open ADFS -> Trust Relationship -> Relying Party Trust

2. Click “Add Relying Party Trust”

3. Click “Start”. Then select “Enter data about the relying party manually”

4. Enter the “Display Name” as your desired, e.g: RSA Archer. Then click “Next”

5. Select “AD FS profile”

6. Click “Next” to skip on the token encryption certificate.

7. Select “Enable support for the WS-Federation Passive protocol” and enter the login URL of

Archer, e.g: https://<FQDN of Archer>/rsaarcher/default.aspx

8. On the section “Configure Identifiers”, click Next as there is already an identifier defined from

previous step, and there is no need to add additional identifier

9. Leave the default settings for multi-factor authentication (i.e: no configuration).

10. Leave the default for choosing issuance authorization rules (i.e: permit all users)

11. On the Final screen, click “Next” to complete the setup

12. Click “close” to close the setup windows. You will then be prompted to define the claim rules for

this Archer endpoint

Setup claim rules for the Archer endpoint This section define what are the attributes that will be passed onto Archer, e.g: (First name, Last

name, username etc). These attributes are known as claims and are stored in the SAML token

1. On the claim rules window, click on “Add Rule”

2. Select “Pass through or Filter an Incoming Claim”

3. Define the claim rule as follows:

a. Give a name for this claim rule, e.g: UPN

b. Define the incoming claim type accordingly, e.g: UPN

c. Select “Pass through all claim values”

4. Repeat the same procedures for other attributes and their claim type, such as those shown

below. Note that if you can’t find all the claim type in the “Incoming claim type” dropdown, go

to next step on how to define them:

a. First name -> First Name

b. Last name -> Last Name

c. Group -> Group

d. Role -> Role

e. Email -> E-mail Address

5. (Optional) Note that ADFS would contain some of these claim type already (depending on your

version of ADFS). You can check all the claim type available in your ADFS as follows

a. Go to ADFS -> Service -> Claim descriptions

b. Look at the “Name” column and see if there is an incoming claim type name matching

from previous step.

c. E.g: Screenshot below show the incoming claim type “E-Mail Address” which matches

with step 4e

d. If you need to create additional claims, then you can click on “Add claim description”

and add them accordingly. Below shows a screenshot of creating an incoming claim type

called “First Name”

e. FYI, here are the definitions of the claims introduced in step 4 and their claim type

schema reference

i. First Name: http://schemas.xmlsoap.org/claims/FirstName

ii. Last Name: http://schemas.xmlsoap.org/claims/LastName

iii. Role: http://schemas.microsoft.com/ws/2008/06/identity/claims/role

iv. UPN: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn

v. Group: http://schemas.xmlsoap.org/claims/Group

vi. E-Mail Address:

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress

Once the claim rules are setup, then ADFS is ready to act as the SP for Archer. The next step is for this SP

to communicate with various IDP

Section 2: Setup ADFS to communicate with various IDP - Internal

domain. As part of the requirement, ADFS is setup on a member server and have access to its AD. As such, ADFS

has a default IDP (a.k.a claims provider trusts) referencing its AD. You can then define what claims to

generate from this default IDP

1. Go to ADFS -> Claims Provider Trusts -> select “Active Directory”

2. Select “Edit Claim Rules”

3. Click “Add Rule” and select “Send LDAP Attributes as Claims”

4. Include the AD attributes as follow:

a. Define a claim name as desired, e.g “Send Through all essential AD attributes”

b. Attribute store: Active Directory

c. Mapping of LDAP attribute to claim types:

i. User-Principal-Name: UPN

ii. Given-Name: First Name

iii. Surname: Last Name

iv. E-Mail-Addresses: E-Mail Address

v. Title: Role (This is optional, only if you want to assign a specific Archer role to

the user)

Sample Title attribute for an user in AD, with value matching the name of Archer role “System

Administrator”

5. To send the group attribute, you need to create a claim rule for each group that associate with

that user. Start by doing select “Add rule” -> Send Group Membership as a Claim. Then populate

the values as follow:

a. Claim rule name: A description of what group you like to include in the claims

b. User’s group: Select the group associate with the user

c. Outgoing claim type: Group

d. Outgoing claim value: The name of that group. E.g: in my screenshot below, the group

name is MyGroup. This way the claim “Group” will contain the actual name of the group

“MyGroup” as the value

e. Repeat step a – d for each of the group you like to send in the claims

Sample Groups associate with the user:

Once this is setup, ADFS is able to communicate with its own AD as an IDP and receive the claims from

generate from its own AD. These claims will then be passed to the relying party trust, i.e: Archer. Since

we have already defined in Section 1 of what claims that will be passed to Archer, and these claims type

matches with the outgoing claims type defined in the IDP claim rules, thus all of the claims will be

passed from IDP to Archer

Section 3: Setup ADFS to communicate with various IDP - External

domain. This section describe how the ADFS is going to communicate with other IDP that exists outside of its

domain. The external domain can be from any vendor (non-Microsoft). We can use SAML as the

communication protocol between ADFS and these IDP. To begin with, obtain the federation metadata

describing the IDP. The federation metadata can be obtained by referencing a URL defined by the IDP, or

it can be obtained in the form of xml. For e.g: if we utilise ADFS as the IDP, then the federation meta URL

will be of syntax:

https://<FQDN of ADFS>/FederationMetadata/2007-06/FederationMetadata.xml

A sample of the xml file is shown below:

FederationMetadat

a.xml

Once you obtained the federation metadata, you can proceed ADFS to communicate with this IDP as

follow

1. Go to ADFS -> Claims Provider Trusts -> Add Claims Provider Trust:

2. Click “Start” to begin. Then input the federation metadata either using the URL or upload the

xml accordingly

3. Once the federation metadata is parsed by the wizard, you will have all the fundamental

components describing the IDP, and there is no need to apply any additional configuration on it.

As such, you can proceed to accept rest of the settings by clicking “Next”.

4. After this, you can proceed to create claim rules for this IDP. If you are being prompted with the

claim rules window, you can proceed to next step accordingly. Otherwise, you can select the IDP

you just created in the “Claims Provider Trusts”, then select “Edit Claim Rules”

5. The next step is to define what claims we expect to receive from the IDP. You will need to

discuss with the operation team who manages this IDP and validate the claims that will be

included. Following are the key questions and validations to be aware of:

a. What are the claims and their claims type schema? E.g:

i. First Name: http://schemas.xmlsoap.org/claims/FirstName

ii. Last Name: http://schemas.xmlsoap.org/claims/LastName

iii. Role: http://schemas.microsoft.com/ws/2008/06/identity/claims/role

iv. UPN: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn

v. Group: http://schemas.xmlsoap.org/claims/Group

vi. E-Mail Address:

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress

Note that the claims type schema is case sensitive. E.g: You can see the claim type for First

Name is end with …/claims/FirstName.

b. Once you obtained these claims description, you will then need to check on your ADFS

to ensure you have these equivalent claims description. Again, the claims type schema

(i.e: the “URL”) is case sensitive. You can check your existing claims description in ADFS -

> Claims Description, or as shown in Section 1 B, step 5

c. If you don’t have the claims type in your claims description, create them according to

the steps given in Section 1 B, step 5.

d. Once your claims descriptions are aligned with those provided by the IDP, you can then

ask for a sample values of these claims to check if we can just pass those values

accordingly, or require any translations. E.g:

i. First Name: Tim

ii. Last Name: Tsang

iii. Upn: tim.tsang@rsa.com

iv. Email: tim.tsang@rsa.com

v. Group: 11qeqe0-qw3qwerw4et-4qq3q45

vi. Role: MyRole133

e. From above example, First name, last name, UPN and email looks reasonable and can be

passed to Archer. However for Group and Role, they might not match with what the

associate group name and role name in Archer, thus you would need to apply a

translation to it.

6. Now that we understand what we are expecting from IDP, we can create claim rules accordingly.

Here is a screenshot for claims that can be pass through without translation:

Here is a screenshot for claims that require translation. You will select the claim rule type as “Transform

an Incoming Claim:

Once you have completed the claim rules, the ADFS is now ready to communicate with this IDP through

SAML and process the claims (SAML token) accordingly. These claims will then be passed to the relying

party trust, i.e: Archer. Since we have already defined in Section 1 of what claims that will be passed to

Archer, and these claims type matches with the outgoing claims type defined in the IDP claim rules, thus

all of the claims will be passed from IDP to Archer

Section 4: Setup ADFS to communicate with various IDP – Microsoft

Azure Active Directory. In this section we look at a specific example of an IDP communicating with ADFS, Microsoft Azure Active

Directory. To start with, we can see how Microsoft Azure is setup to communicate with ADFS as the SP

1. In Microsoft Azure, we will first define an Enterprise Application for Archer. It needs to be

defined as an “Non-Gallery Application”

2. Define Single Sign-on options using “SAML-based Sign-On”

3. Define ADFS and Archer properties in this application as follows:

a. Identifier Upload the federation metadata of your ADFS to populate this field. By default

it will be: http:// <FQDN of ADFS>/adfs/services/trust

b. Reply URL: Upload the federation metadata of your ADFS to populate this field. By

default it will be https://<FQDN of ADFS>/adfs/ls

c. Click on “Show advanced URL settings” and populate the Sign on URL as follow:

https://<FQDN of Archer>/rsaarcher/default.aspx?realmid=<IDP>. We will define <IDP>

further in next section (Section 5: Setup Archer SSO with Federation). In the meantime,

you can use the one in the example, my.azure.ad

4. Define the list of SAML token attributes to send to Archer. Note that you must define the Name

and namespace for each of the attribute and they need to match with the claim type schema

(the “URL”) in your ADFS claim description (and again, it’s case sensitive). E.g: For defining First

Name in the SAML Token attributes

a. Name: FirstName

b. Value: user.givenname

c. Namespace: http://schemas.xmlsoap.org/claims

This will translate as the claim type schema of http://schemas.xmlsoap.org/claims/FirstName. It

will utilise the user.givenname attribute within the Azure Active Directory

5. For sending group attribute, you will need to be aware of the following:

a. You need to first enable the application to send group claim.

(Home -> Azure Active Directory -> App Registration -> <Your Archer app> -> manifest -> change

“groupMembershipClaims”: “All”

b. Also, Azure contain the group attribute of a user using the claim type schema of

http://schemas.microsoft.com/ws/2008/06/identity/claims/groups.

c. Finally, the group attribute will be send using the Object ID instead of the convention

name

(Home -> Azure Active Directory -> Groups – All groups -> <your group> -> note the Object ID)

6. For sending role attribute, you would need to be aware of the following:

a. Azure Active Directory already has a role attribute and is assigned claim type schema:

http://schemas.microsoft.com/ws/2008/06/identity/claims/role. Thus, you can’t use

this claim to pass Archer role to Archer, otherwise you will be sending Azure AD role to

Archer, and not the Archer role as you defined in Archer.

b. To define a Archer role attribute to a user, you would need to use an another attribute

within Azure Active Directory, e.g: Job Title

c. You will also need to define a specifics claim type schema in the SAML token attribute to

store value in the Job Title attribute, e.g: http://schemas.xmlsoap.org/claims

7. Once these are done, obtain the federation metadata URL or the xml of this IDP.

8. Finally, define the list of users who can utilise the Archer application

9. On ADFS, define the claim provider trust for Azure by using the federation metadata obtained in

step 6.

10. Creating the claim rules for all the SAML token attributes

a. For UPN, FirstName, Last Name and Email, we can use a pass through method

b. For Group, we will need first need to create an claim description, such as

AzureGroupsID, to describe that claim type schema of Azure Group

c. Then use a transform claim method to apply translation to convert that Object ID into

convention group name that is present in Archer

d. Similarly with role, you will first need to define a claim type, e.g: Mrole. It will have

schema of http://schemas.xmlsoap.org/claims/role

e. You will then create a claim rule using the transform method to covert the incoming

claim type of Mrole back to the original role claim. This is because the relying party trust

(the Archer end point) is expecting the role claim in the claim rules (and not Mrole)

Section 5: Setup Archer SSO with Federation The final steps involve configuring Archer to communicate with ADFS, as well as defining the list of IDP

which users can select to authenticate with

1. Open Archer Control Panel -> Installation settings -> Federation Metadata. Locate the xml

format of the ADFS federation metadata. As a refresh, you can download the federation

metadata using the URL:

https://<FQDN of ADFS>/FederationMetadata/2007-06/FederationMetadata.xml

2. Go to your instance -> Single Sign On. Then define the common parameters for SAML

authentication:

a. Select Federation and optionally select manual bypass if you still like to use internal user

to login

b. In the relying party identifier, type in the Archer login URL, e.g: https://<FQDN of

Archer>/rsaarcher/default.aspx. This need to be the same as section 1 a, step 7

c. In the Home Realm Parameter, enter realmid. This is matching with the reply URL

defined in section 4, step 3. This is how key name for defining the different IDP we want

to connect with

3. Define the common parameters for selecting IDP:

a. Decision page header: What you like to see in the login page to indicate this is using

SAML authentication. E.g: Federation Login

b. Dropdown label: Advise user to select an appropriate IDP to authenticate with. E.g:

Select your Identity Provider

4. Define an IDP that you want user to authenticate with. Click the + button to add. Then define:

a. Realm: A short form of your IDP. E.g: archer.local, mycorp.local, azure.ad. This doesn’t

need to associate with your IDP in any way, but do ensure there is no space involve.

Note that for Section 4, step 3, we have mentioned to define the reply URL as:

https://<FQDN of Archer>/rsaarcher/default.aspx?realmid=<IDP>, where <IDP> is

azure.ad. The Realm in here is the <IDP> for that URL. This URL is a shortcut for user to

authenticate with that IDP without selecting the IDP in the dropdown.

b. Identifier: The URL indicating the IDP. You can obtain this ADFS -> Trust Relationships ->

Claims Provider Trusts -> <your IDP> -> properties -> Identifiers tab -> claims provider

identifier

For your own internal domain, the identifier can be obtained by going to ADFS -> service -> edit

federation service properties -> General tab -> Federation Service identifier

c. In the Display name, provide a description of which IDP you want to authenticate with

d. Define provisioning settings such as whether you want to update user groups, roles,

details each time the user is login to Archer. This is known as the Just-In-Time

provisioning

e. Repeat a – d for each of the IDP you have configured in ADFS

5. Now that everything has been setup. You can login to Archer using the usual URL,

https://<FQDN of Archer>/rsaarcher/default.aspx. Once you can select which IDP to

authenticate, you will be prompted by the desired IDP and enter the credentials below to that

IDP.

List of IDP

Using internal domain as IDP

Using external domain as IDP

Using Microsoft Azure Active Directory as IDP

Using the realmid parameter in the URL to bypass IDP selection:

For Azure, you can also use the Azure Self Service portal, https://myapps.microsoft.com and select your

Archer application to login as well.