Agent for Windows Authentication Guide › Introduction to the Federation Agent for Windows Authentication

Introduction to the Federation Agent for Windows Authentication

Overview of the Federation Agent for Windows

The Federation Agent for Windows Authentication lets users on systems implementing one of the Integrated Windows Authentication (IWA) protocols to federate with business partners.

When a user requests access to a protected resource, the federation system uses the log-on identity information from a third-party web access management (WAM) system. This process of using the third-party WAM is known as delegated authentication. The federation system redirects the request to the Federation Agent. The Agent verifies the user identity, creates an open format cookie, and passes the cookie to the federation system. The system then generates a SAML assertion and passes it to the relying party.

Note: See the Federation Standalone Guide for information about delegated authentication.

IWA supports the Windows NT LAN Manager (NTLM) and Kerberos encryption protocols. On a Windows system, the Federation Agent can use NTLM or Kerberos. On a UNIX system, the Federation Agent can only use Kerberos.

The Federation Agent is installed on the same Windows or UNIX system where CA SiteMinder® Federation Standalone is installed. The following restrictions apply:

• The Federation Agent is incompatible with federation installations using the CA SiteMinder® Connector.
• The browser issuing a single sign-on (SSO) request cannot be on the same system as the federation system.

The administrator must know about the Integrated Windows Authentication protocols—NTLM and Kerberos. In addition, the reader must be familiar with federation concepts and CA SiteMinder® Federation Standalone administration.

SSO between a System using IWA and a Business Partner

A delegated authentication use case shows how the Federation Agent works. A department store wants to grant single sign-on access to employees of their supplier, ForwardInc Sporting Goods, to provide them with special discounts.

The department store and ForwardInc Sporting Goods have an established federated partnership. Employees of ForwardInc Sporting Goods typically log in to their account at work with their domain user name and password. When an employee visits the department store web site, the employee is granted access through one of the IWA protocols without being challenged.

The following graphic shows the role of the Federation Agent in a federated partnership:

The transaction as shown in the diagram is as follows:

1. The user logs in to the web access management (WAM) system at ForwardInc Sporting Goods.
2. The user opens a browser and navigates to the URL for the department store at the relying party.

   Note: The browser cannot be on the same system where the federation system with the Windows Agent is installed.

3. The relying party sends an authentication request to the asserting party. The federation system at the asserting party determines that delegated authentication is configured for this partnership.
4. The federation system sends a request to the Federation Agent. The Agent validates the security context for the user.
5. The Windows Agent extracts the validated information from the request.
6. The Windows Agent places the user information into an open format cookie.
7. The Windows Agent sends the cookie to the federation system.
8. The federation system at the asserting party extracts the user information, places it in an assertion, and sends the assertion to the relying party.

The user is granted access to the department store web site without having to log in.

Terminology

This guide uses the following terms related to Windows authentication:

Authentication Sever (AS)

The authentication server is the part of the key distribution center (KDC) that replies to the initial authentication request from the client. After the user is authenticated, the authentication server issues a ticket granting ticket (TGT). Using the TGT the user can obtain other Kerberos service tickets without having to re-enter a password.

Integrated Windows Authentication (IWA)

Integrated Windows Authentication provides Windows client application with authentication information from a user's log-on credentials. If the authentication exchange fails to identify the user, the browser prompts the user for a Windows ID and password. Integrated Windows Authentication is not a standard or an authentication protocol; it uses either the Kerberos or NTLM protocols.

Kerberos

The Kerberos authentication protocol lets users communicate safely over any network. Kerberos is also a suite of free software published by Massachusetts Institute of Technology (MIT) that implements this protocol. Kerberos uses tickets for verifying user identity. Kerberos protocol messages are protected against eavesdropping and replay attacks. Kerberos builds on symmetric key cryptography and requires a trusted third party, the key distribution center.

Key Distribution Center (KDC)

A key distribution center is part of a cryptographic system, which includes an authentication server and a ticket granting server. The purpose of a key distribution center is to reduce the risks inherent in exchanging keys. Key distribution centers often operate in systems where some users can have permission to use certain services at some times and not at others.

Keytab

A keytab is a file containing pairs of Kerberos principals and encrypted keys derived from the Kerberos password. This file is used for logging into the key distribution center.

NTLM

NTLM is an authentication protocol used in various Microsoft network implementations for single sign-on. NTLM employs a challenge-response mechanism for authentication, in which clients prove their identities without sending a password to the server. NTLM consists of three messages, commonly referred to as Type 1 (negotiation), Type 2 (challenge) and Type 3 (authentication). The responses in the Type 3 message are the most critical, because they prove to the server that the client user knows the account password.

Ticket Granting Ticket (TGT)

The ticket granting ticket (TGT) is a small, encrypted identification file with a limited validity period. After authentication, this file is granted to a user for data traffic protection by the KDC authentication server. The ticket granting ticket file contains the session key, the expiration date of the ticket, and the user IP address.

Ticket Granting Server (TGS)

The ticket granting server is the KDC component that distributes service tickets to clients with a valid ticket granting ticket (TGT). The ticket granting server is like an application server that issues tickets as a service.

NTLM Protocol

NTLM includes various authentication and session security protocols. NTML is based on a challenge-response model, consisting of three types of messages that are exchanged in the following order:

1. The client sends a type 1 message (negotiation) to the server. The type 1 message specifies the features that are supported by the client and requested of the server.
2. The server sends a type 2 message (challenge) to the client. The primary function of this message is to challenge the identity of the client user.
3. The client sends a type 3 message (authentication) to the server. The type 3 message includes the domain and user name of the client user and responds to the challenge in the type 2 message.

The following graphic shows how the federation system with the Federation Agent use the NTLM protocol:

The following process references annotations in the preceding diagram:

1. An authentication request is made to federation system at the asserting party.
2. The federation system recognizes the request as a delegated authentication request and redirects to the request to the Federation Agent.
3. The Agent sends a response back to the browser.
4. If the browser is configured for IWA, the browser sends an NTLM Negotiate token (type 1 message) in the authorization header to the Federation Agent.
5. The Federation Agent sends an NTLM Challenge token (type 2 message) to the browser.
6. The browser sends an NTLM Authenticate token (type 3 message) to the Federation Agent.
7. If a security context is associated with a user, the Federation Agent retrieves the user identity from the established context.
8. The Agent creates an open format cookie containing the user identity information.
9. The Agent sends the cookie to the federation system.
10. The federation system sends an assertion to the relying party to complete federation processing.

Kerberos Protocol

The following illustration shows how the federation system with the Federation Agent use the Kerberos protocol:

The following process references annotations in the preceding diagram:

1. An authentication request is made to the federation system at the asserting party.

   The federation system recognizes that this request is a delegated authentication request.

2. The federation system redirects to the Federation Agent.
3. The Federation Agent requests an HTTP authorization from the browser.
4. If the browser is configured for IWA, it sends a SPNEGO token to the Federation Agent. This token allows initiators and acceptors to negotiate whether to use Kerberos or NTLM.
5. The Federation Agent extracts a Kerberos token from the SPNEGO token.
6. After the security context is established from the Kerberos token, the Agent retrieves the user identity information.
7. The Agent creates the open format cookie and builds a redirect URL.
8. The Agent sends the cookie to the federation system.
9. The federation system does the required processing and sends an assertion to the relying party.