What is ADFS?

Some definitions:

ADFS (Active Directory Federation Services) is a component in Microsoft® Windows Server™ 2003 R2 that provides Web single-sign-on (SSO) technologies to authenticate a user to multiple Web applications over the life of a single online session. See http://technet.microsoft.com/en-us/library/cc786469(v=ws.10) 

AD FS is Microsoft’s implementation of the WS-Federation Passive Requestor Profile protocol (passive indicates that the client requirements are just a cookie- and JavaScript-enabled Web browser). AD FS implements the standards based WS-Federation protocol and Security Assertion Markup Language (SAML).

ADFS is a software component developed by Microsoft that can be installed on Windows Server operating systems to provide users with single sign-on access to systems and applications located across organizational boundaries. It uses a claims-based access control authorization model to maintain application security and implement federated identity.[1]

ADFS integrates with AD as well as Active Directory Application Mode (ADAM). The latter is used, for example, to store external users (e.g. customers). It is a kind of light weight AD.

ADFS extends Active Directory so that it can be used for web applications to authenticate users which are NOT in the Active Directory (AD).

For applications that support extranet users that do not exist in Active Directory, the DirectControl for Java/Web solution can be used to integrate with identity stores that are separate from Active Directory. The technical approach that DirectControl uses for web single sign-on is a Microsoft technology called ADFS. ADFS is a freely available set of services in Windows Server 2003 R2 and 2008. ADFS provides two primary functions:

  • Routing requests that come in from external users to the appropriate ADFS server for authentication.
  • Issuing security tokens to users upon successful authentication.

SAML protocol

ADFS supports SAML as the underlying authentication protocol. Spring Security has a SAML extension, supporting ADFS 2.0 on SAML 2.0.

SAML is an XML-based, open-standard data format for exchanging authentication and authorization data between parties, in particular, between an identity provider and a service provider.  

The SAML specification defines three roles:

  • The principal (typically a user)
  • The identity provider (IdP)
    This is in fact the ADFS. An Identity Provider (IdP), also known as Identity Assertion Provider, is responsible for (a) providing identifiers for users looking to interact with a system, and (b) asserting to such a system that such an identifier presented by a user is known to the provider, and (c) possibly providing other information about the user that is known to the provider. This may be achieved via an authentication module which verifies a security token that can be accepted as an alternative to repeatedly explicitly authenticating a user within a security realm
  • The service provider (SP) 
    This is the Principal toolbox, in our case, also the Relying party, i.e. relying on ADFS to check the claims that are made (“I claim that I am userX”). In ADFS you configure a relying party trust to tell ADFS where it can expect claims to come from – it will trust the relying party so that when a user is authenticated they can be redirected back to that application 

In the use case addressed by SAML, the principal requests a service from the service provider. The service provider requests and obtains an identity assertion from the identity provider. 


ADFS Versions

  • AD FS 1.0 – Windows Server 2003 R2 (additional download)
  • AD FS 1.1 – Windows Server 2008 and Windows Server 2008 R2
  • AD FS 2.0 – Windows Server 2008 and Windows Server 2008 R2 (download from Microsoft.com)
  • AD FS 2.1 – Windows Server 2012
  • AD FS 3.0 – Windows Server 2012 R2

Two SSO cases

See also images below. 

  1. Authenticate “external users”, e.g. customers. In this case, the user can be authenticated by for example ADAM.  Single sign-on from a user directory that resides in the same security domain as the application.
  2. Authenticate users of one organization, with its own AD, on the application server of another organization. A deployment that “trusts” another domain to authenticate users and provided a signed token with the “claims” regarding the user.

ADFS SSO support in the Principal Toolbox

In Java, there are two options (source: http://stackoverflow.com/questions/22908548/single-sign-on-in-spring-by-using-saml-extension-and-shibboleth)

  • Spring Security SAML Extension: component enables both new and existing applications to act as a Service Provider in federations based on SAML 2.0 protocol and enable Web Single Sign-On. Spring Security Extension allows seamless combination of SAML 2.0 and other authentication and federation mechanisms in a single application. All products supporting SAML 2.0 in Identity Provider mode (e.g. ADFS 2.0, Shibboleth, OpenAM/OpenSSO, RM5 IdM or Ping Federate) can be used to connect with Spring Security SAML Extension.
  • Shibboleth (also as SP): Shibboleth is a web-based technology that implements the HTTP/POST, artifact, and attribute push profiles of SAML, including both Identity Provider (IdP) and Service Provider (SP) components.

The Spring SAML extension is described here:

Spring site: http://projects.spring.io/spring-security-saml/ 

Guide: http://docs.spring.io/autorepo/docs/spring-security-saml/1.0.x-SNAPSHOT/reference/htmlsingle/#chapter-introduction

There is Spring integration guide for ADFS: http://docs.spring.io/spring-security-saml/docs/current/reference/html/chapter-idp-guide.html

Was this article helpful?

Related Articles