IT Connect
Information technology tools and resources at the UW

Active Directory Federation Service

ADFS provides Single Sign On (SSO) authentication services to web applications that support the WS-Federation and WS-Trust protocols¹. ADFS allows an application to be able to authenticate users with UW NetIDs.

ADFS is available if you need to integrate an existing web application that relies on WS-* claims-based authentication–it is not an appropriate solution for newly developed applications. We recommend the use of the Shibboleth Service Provider for developers of new web applications–see the Authentication service catalog link below.

On This Page Related to This Page

 

Background

A web application that uses ADFS is known as a Relying Party (RP)4. In order for an RP to work with ADFS, the RP and ADFS must have information about each other. This information is referred to as metadata.

During the installation process the RP can retrieve the ADFS metadata from https://sts.netid.washington.edu/FederationMetadata/2007-06/FederationMetadata.xml. The RP operator provides their RP metadata to ADFS through the procedure described below.

In addition to providing user authentication and single sign-on (SSO) for web applications, ADFS provides the capability to release additional user information to an RP at authentication time. This user information is presented as name-value pairs known as claims. In the UW environment, ADFS login requests are routed to the Shibboleth Identity Provider (IdP) and the Weblogin service for validation. Claims data can be sourced both from the IdP and from the NETID Active Directory. In Shibboleth/SAML terminology claims are sometimes referred to as “attributes.”

Claims are useful for access control decisions and personalization within the RP application. By default, the three claims noted below are issued from ADFS. If you require any other claims you will need to specify them and provide a business justification for this information; explain why your application needs that data5. For group claims, specify the particular group(s) or stem(s) required by your RP. Use the UW Groups Service to determine the appropriate groups ids. We don’t release “all groups” to any RP.

Default claims:

  • Name – normally the user-friendly name, not the UW-NetID
  • Authentication time
  • Authentication method

 

Requesting an ADFS Relying Party Trust

Prerequisites

  1. You have installed and configured a claims-aware application or are using a cloud hosted application that requires ADFS.
  2. You’ve gathered all your metadata and RP contact information.
  3. You know what claims are required by the application.
  4. You are a registered contact for the DNS name of your application in UW DNS or you are listed as a domain contact in “whois” data. This requirement may not apply if you are using a cloud hosted (SaaS) application.
  5. Optional: If your RP requires signed authentication requests and/or encrypted authentication responses, you have created and installed an X.509 certificate for these purposes. In most cases your RP shouldn’t need to do either.

Procedure

Send your request to help@uw.edu This will create a ticket in our request tracking system. Include the following information:

  1. RP contact info: Name, email address, phone number, and role for two contacts. Each contact should have their role designated as Administrative, Technical, or Support.
  2. RP metadata:
    1. If your RP supports it, include the URL to your metadata endpoint (e.g. https://host.dept.washington.edu/FederationMetadata/2007-06/).
    2. If your RP doesn’t have a metadata URL but it can produce a metadata file, attach the metadata file to your request.
    3. If your RP can’t support either of the above two options, then provide the following information in your request email:
      1. RP Name – a “friendly” name to identify the application
      2. RP EntityID (by default the RP’s application URL)
      3. Optional: Base-64 encoded public key of your X.509 certificate if your RP requires signed authentication requests or encrypted responses.
  3. Optional:
    1. Include a list of additional required claims & business justification for them.
    2. If you need to support 2-factor authentication (UW NetID plus Duo hardware token) include this in your request.

A support engineer will receive and process your request. They will respond to your request if they have any questions or when the request has been fulfilled.

 

Notes

¹ Microsoft uses the phrase “claims-based authentication” to describe the use of these protocols. They are similar to the well-known SAML protocol used by the UW Weblogon service. Microsoft documentation often conflates the SAML protocol with the SAML authentication token format. ADFS does not support RPs (Service Providers in SAML terminology) that use the SAML protocol. The WS-Federation specification authors borrowed many of the SAML constructs including the token format and the metadata format. However, the protocol and metadata are not interoperable.

² This is a high level document from Microsoft that defines the components and describes their relationship

³  Official Microsoft Documentation

4 RPs are typically .Net applications built on top of Windows Identity Foundation (WIF) or Active Directory Authentication Library (ADAL).

5 Some claims data is considered sensitive or confidential and has approval processes that must be completed before the requested claims can be released to your Relying Party. If we need more information to get those approvals, we’ll let you know.