Active Directory Federation Services
This guide provides common steps for setting up Active Directory Federation Services (ADFS) as a SAML provider for Rackspace Identity Federation. While the defaults might work in many situations, please consult the ADFS documentation for any implementation-specific details.
Configure ADFS
Use the following steps to set up an ADFS-relying party trust with Rackspace.
- Click Add Relying Party Trust in your ADFS Management Console.
- Import the Rackspace metadata by using https://login.rackspace.com/federate/sp.xml or by downloading the https://login.rackspace.com/federate/sp.xml metadata file locally and then uploading it in ADFS.
- After you have created the Rackspace-relying party trust, edit the claim rules for that trust.
- Create an Issuance Transform Rules claim rule for email, and use the User-Principle-Name as an outgoing claim type.
- Create outgoing claim of type Name ID.
Attribute mapping for ADFS
The normal method for mapping ADFS users to Rackspace roles or permissions is to use ADFS Groups. This guide gives an example of setting up your Attribute Mapping Policy to send both the ADFS Groups to which users belong and user information as SAML assertions for proper mapping.
Use the following steps for ADFS attribute mapping:
- Go to the Claim rules for the Rackspace relying-party trust that you set up, as shown in the following image:
- Add a new rule for the LDAP Attribute named Token-Groups - Unqualified Names with an Outgoing Claim Type of Group, as shown in the following image:
To learn more about customizing how you include Active Directory group membership in your SAML attributes, see https://msdn.microsoft.com/en-us/library/ff359101.aspx.
The following example shows a Rackspace YAML (.yml
) Attribute Mapping Policy that you can use when you configure your Identity Provider with Rackspace. This example assumes that you have a group named rackspace-billing
with users who you want to access Rackspace billing services by using the billing:admin
Rackspace role.
More information
When you map ADFS users to Rackspace roles or permissions, ensure that you perform the following tasks:
- Change the
groups
specified in the example to match your configured outgoing claim type for the ADFS groups. - At a minimum, remember to update the example’s
domain
value to your Identity Domain, which is found on the Details page for the Identity Provider. - Validate that any values that are mapped to
email
andexpire
are properly specified for your specific SAML attributes or assertions. For example, in the following example policy,email
is set by using the path ("{Pt}"
) syntax in the Attribute Mapping Policy language to point to theNameID
attribute in the SAML assertion, as shown in the following example:
mapping:
rules:
- local:
faws:
groups:
multiValue: true
value: "{Ats(http://schemas.xmlsoap.org/claims/Group)}"
user:
domain: "your_domain_id_goes_here"
# Update to your Identity Domain from the Identity Provider details page
email: "{Pt(/saml2p:Response/saml2:Assertion/saml2:Subject/saml2:NameID)}"
expire: PT4H
# This would configure a maximum session duration of 4 hours, you might want to set this to a SAML-provided value
name: "{D}"
# This value matches to the SAML attribute "name" by default.
roles:
- "{0}"
# This substitution states to take the value of the return from the first element of the remote role.
remote:
- multiValue: true
path: |
(
if (mapping:get-attributes('http://schemas.xmlsoap.org/claims/Group')='rackspace-billing')then 'billing:admin' else ()
)
# The groups specified here are examples. You should substitute your own groups.
version: RAX-1
- Ensure that you validate and modify the following items in your own Attribute Mapping Policy:
- The ADFS groups that users belong to and to which you want to map specific Rackspace permissions.
- The
expire
value or path. - The
email
value or path.
For more examples and a complete guide to the Attribute Mapping Policy language, see the Appendix: Attribute Mapping Policy Reference.
Updated 10 months ago