Single Sign On (SSO) with ADFS

Overview

This article covers how TeamDynamix clients have configured Microsoft Active Directory Federation Services (ADFS) to allow Single Sign-On authentication with TeamDynamix. Clients have been able to successfully configure both ADFS 2.0 and ADFS 3.0+ to work with TeamDynamix.

Prerequisites

Before you can configure ADFS as outlined in this article, please make sure to:

1. Download your ADFS metadata and extract the Entity ID. You will need to enter this in the Entity ID field in TDAdmin.
2. Provide your public metadata URL to your TeamDynamix implementation consultant. TeamDynamix will need to add your metadata to our internal systems before your SSO will work.

ADFS 2.0 Configuration

ADFS must be configured specifically to "talk" to our Shibboleth SP. Microsoft has published a step-by-step guide about how to configure ADFS in this way. The URL is included below. The Step 2 > Configure AD FS 2.0 section of the article is the portion which needs to be completed by the client. Do not worry about the Step 2 > Add the Scope Element to AD FS 2.0 Metadata or Step 2 > Configure Shibboleth sections. You do not need to complete any other portions of this guide either.

It should be noted that Shibboleth will scope the EPPN attribute on the TeamDynamix side to append the @myuniversity.edu, but the EPPN must be sent over from ADFS in that same matching format so that Shibboleth will understand it. This is what the Claims Rules portion of the guide is talking about.

Microsoft ADFS 2.0 Guide to configure ADFS as an SSO IdP for a Shibboleth SP:
http://technet.microsoft.com/en-us/library/gg317734(v=ws.10).aspx

ADFS 3.0+ Configuration

For the most part, the steps for configuring Microsoft ADFS 3.0+ to work with TeamDynamix are the same as the ADFS 2.0 steps. It appears that Microsoft ADFS 3.0+ does have some differences in how to configure their claims to release attributes though. Below are some examples of how clients have successfully configured their ADFS 3.0+ claims to properly release attributes for Single Sign On.

Figure 1

This depicts an entire set of claims rules for SSO with TeamDynamix. Note that the client is mapping the LDAP attributes to claims (1) and then defining claim rules for EPPN (2 & 3), Email Address (4), First Name (5) and Last Name (6).

Figure 2

This depicts the rule to map each LDAP attribute the client wishes to release to TeamDynamix to a claim type. The claims themselves (shown later) are the attributes that TeamDynamix receives as a part of the SSO authentication request back from the client. Note that the rule template used is Send LDAP Attributes as Claims.

Figure 3

This depicts the rule to transform an AD UPN attribute to the standard SAML 2.0 eduPersonPrincipalName attribute, or EPPN. This is the username attribute which comes out of ADFS. Note that the rule template used is Send Claims Using a Custom Rule.

Copy and paste:

c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"] => issue(Type = "urn:oid:1.3.6.1.4.1.5923.1.1.1.6", Value = c.Value, Properties ["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/attributename"] = "urn:oasis:names:tc:SAML:2.0:attrname-format:uri");

Figure 4

This depicts the rule which will transform the AD Group attribute to the standard SAML 2.0 eduPersonScopedAffiliation attribute. Microsoft recommends adding this rule in addition to the previous UPN to epPN rule. Note that the rule template used is Send Claims Using a Custom Rule.

The value highlighted in red is the scope portion of the scoped affiliation. The format, according to Microsoft, should be member@scope. The scope of scoped affiliation should match the scope of your EPPN (sourced from UPN) value. For instance, if your EPPN values to come out scoped as user@abcuniversity.edu, the value in red would be member@abcuniversity.edu.

Copy and paste, then change the FIXME portion to be replaced with the same domain your EPPN values will have.

c:[Type == "http://schemas.xmlsoap.org/claims/Group", Value == "Domain Users"] => issue(Type = "urn:oid:1.3.6.1.4.1.5923.1.1.1.9", Value = "member@FIXME", Properties ["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/attributename"] = "urn:oasis:names:tc:SAML:2.0:attrname-format:uri");

Figure 5

This depicts the rule to transform an AD E-mail Address attribute to the standard SAML 2.0 Mail attribute. Note that the rule template used is Send Claims Using a Custom Rule.

Copy and paste:

c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"] => issue(Type = "urn:oid:0.9.2342.19200300.100.1.3", Value = c.Value, Properties ["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/attributename"] = "urn:oasis:names:tc:SAML:2.0:attrname-format:uri");

Figure 6

This depicts the rule to transform an AD GivenName attribute to the standard SAML 2.0 givenName attribute. Note that the rule template used is Send Claims Using a Custom Rule.

Copy and paste:

c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname"] => issue(Type = "urn:oid:2.5.4.42", Value = c.Value, Properties ["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/attributename"] = "urn:oasis:names:tc:SAML:2.0:attrname-format:uri");

Figure 7

This depicts the rule to transform an AD Surname attribute to the standard SAML 2.0 surname attribute. Note that the rule template used is Send Claims Using a Custom Rule.

Copy and paste:

c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname"] => issue(Type = "urn:oid:2.5.4.4", Value = c.Value, Properties ["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/attributename"] = "urn:oasis:names:tc:SAML:2.0:attrname-format:uri");

Conclusion

You can view the full list of attributes TeamDynamix accepts and the format that they should be in by reviewing the  Accepted SAML SSO Attributes article. These attributes can be used in additional claims rules to release more information to TeamDynamix when authenticating via SSO.

Once the ADFS configurations have been completed by the client, they will need to provide TeamDynamix with the public URL where their metadata is available. TeamDynamix will add this to the store of metadata they regularly download. The client can then work with our Professional Services team to complete SSO configurations in TeamDynamix and turn on SSO.