This project is read-only.

1      Introduction

This document provides a detailed design for amending Acme’s existing ADFS service to support both Forms Based Authentication (FBA) and Integrated Windows Authentication (IWA).

Out-of-the-box, an ADFS server supports a single default authentication method for all service providers (aka relying partners). Currently, IWA is used with all existing service providers.

ADFS will be configured to trust the additional service provider Acme. Due to sensitive data, it is mandatory that the user will be challenged for their domain credentials via a sign on page every time they start a new Acme session, to prevent other users using their PCs while away from their desks. FBA will be used for Acme.

2      Design Overview

2.1      Architectural Summary

This design is an amendment to Acme’s existing ADFS server. The change is to enable ADFS to dynamically select an authentication method based on the service provider that the user wishes to access; and to require the user to be re-authenticated every time they access a service provider.

2.2      Overall description

2.2.1       Textual description

The change will consist of three parts (1) forcing a user to be authenticated each time they access a service provider, (2) dynamically selecting authentication method and (3) trusting Acme, out of scope.

2.2.1.1       Forcing Authentications

ADFS Single Sign On will be switched off via its configuration file.

<singleSignOn enabled="false" />

 

The experience of users accessing a service provider where the user is authenticated by Integrated Windows Authentication will not be affected, as this authentication method involves no user interaction.

The experience of user accessing a service provider (Acme) where the user is authentication by Forms Based Authentication will be a challenge every time to fill in the ADFS sign in page.

2.2.1.2       Selecting Authentication Method

ADFS default authentication method is specified in its configuration file. It will be changed from Integrated Windows Authentication to Forms Based Authentication using an edited version of the ASP.Net page called FormsSignIn.aspx.

   <localAuthenticationTypes>

     <add name="Forms" page="FormsSignIn.aspx" />

     ...

   </localAuthenticationTypes>

 

An addition an extra appSetting element will be added to its configuration file. The name of the setting is fbaRelyingPartners and its value is a comma separate list of service provider hostname. FBA will be used for service providers in the list, and IWA will be used for service providers not in the list.

<appSettings>

   ...

   <add key="fbaRelyingPartners" value="<acme hostname>" />

</appSettings>

 

The load method of the FormsSignIn page will contain logic to discover the service provider the user wishes to access. The method will then check if the authentication method of that service provider is FBA by whether it appears in the list of FBA Relying Partners. If the required authentication method is not FBA then the user will be redirect to the ADFS URL that authenticates users using Integrated Windows Authentication. Otherwise the user will remain on the FormsSignIn page and will be authenticated using Forms Based Authentication.

The load method of the FormsSignIn page has to handle four sign on use cases:

  •  Sign On Initiated via ADFS IdpInitiatedSignOn page

The user’s initial request is to ADFS’ IdpInitiatedSignOn. ADFS generates a SAML Request containing AuthnRequest XML. The Audience element in AuthnRequest identifies the service provider. The user is then redirected to FormsSignIn page, with SAML Request in the URL’s query string. The SAML Request is compressed (RFC1951) and Base64 encoded.

  •  Sign On Initiated via Service Provider, and the Service Provider uses SAML SSO Post Binding

The user’s initial request is to the service provider. The service provider generates a SAML Request containing AuthnRequest XML. The service provider is identified by AuthnRequest's Issuer element. The service provider generates a HTML response with a FORMS tag and a field set to Base64 encoding of the SAML Request; and javascript causing the client to automatically POST the form to ADFS. The user request will be routed to FormsSignIn page. ADFS automatically embeds the SAML Request in an MSI SAML Request parameter which is also Base64 encoded.

  • Sign On Initiated via Service Provider, and the Service Provider uses SAML SSO Redirect Binding

The user’s initial request is to the service provider. The service provider generates a SAML Request containing AuthnRequest XML. The service provider is identified by AuthnRequest's Issuer element. The service provider generates a HTML 302 (redirect) response which redirects the client to ADFS. The redirect URL includes the SAML Request in its query string. The SAML Request is compressed (RFC1951) and Base64 encoded.

  • Sign On Initiated via Service Provider, and the Service Provider uses WS-Federation protocol

The user’s initial request is to the service provider. The service provider generates a HTML 302 (redirect) response with redirecting the client to ADFS. The redirect URL includes wtrealm in its query string. wtrealm is a string identifying the service provider.

The logic of the load method is detailed in the flow diagram in downloads.

3 Terms and Abbreviations 

Term/Abbrev

Definition

ADFS

Active Directory Federation Service

HTML

Hyper Text Mark-up Language

IdP

Identity Provider

IWA

Integrated Windows Authentication

SAML

Security Assertion Mark-up Language

SP

Service Provider

SSO

Single Sign On

XML

Extensible Mark-up Language

  

Last edited Jul 24, 2012 at 1:57 PM by slang, version 5

Comments

No comments yet.