Embed Size (px)
Citation preview
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: [email protected]
iv. Email: [email protected]
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.
