Active Directory Federation Services
How does it really work?
John Craddock
johncra@xtseminars.co.uk
Application Authentication
• Within your environment Windows
Authentication provides single sign-on for all
applications
– Windows Authentication provides details of the
authenticated user and group membership
Developer Challenges
• If the developer wants Active Directory
held information about the user, it requires
attribute value extraction
– Developer must understand AD
– Hardcoded LDAP query strings
– Continual reinvention of the wheel
Access from the Internet
Kerberos,
NTLM, Basic,
Digest, Forms?
• Without a VPN, DirectAccess or authentication
proxy solution
– Kerberos fails
– Requires developers to use a different authentication
model
Application in the Cloud
• How do we handle authentication if we move an
enterprise application to the cloud?
• The Microsoft BPOS dedicated service colocates the organisation’s AD directory
– Your DCs are hosted in the Microsoft datacentre
Allowing Access by Partners
• Requires YOU to hold account and profile details for
all of your partner’s users that need to access the
application
– YOU must manage the life-cycle of those users
• Does your partner keep you informed of changes?
– The partner’s users need to remember yet another
password
The Answer
• Create an identity (includes authentication)
framework that can be consumed by all
applications regardless of their location
• Allow the identity token to carry more information
than just the user and group memberships
• Trust your partners to authenticate their users
• Solution based on industry standard protocols
• Make it work for browsers and web services
The Solution
Federation of Identity
• Many players in the game…
• Microsoft solution
– Active Directory Federation Services
• The latest release AD FS v 2.0
Issuer
Identity Provider (IP)
Security Token Service (STS)
Key Concepts
User / Subject /Principal
The Security Token
Contains claims about the user
For example:
• Name
• Group membership
• User Principal Name (UPN)
• Email address of user
• Email address of manager
• Phone number
• Other attribute values
Signed by issuer
Authentication request
ST
Active
Directory
Issues Security Token
Security Token “Authenticates”
user to the application
Relying party /
Resource provider
Trusts the Security Token
from the issuer
Claims-Aware Application
• The application makes authorization decisions
based on the claims contained in the security
token
– No longer required to make authentication decisions
• Same authorisation logic for Application
– Deployed on the Intranet or as a Cloud service
– Receiving claims from its own organization’s users or
users from trusted partners
Building Claims-Aware Applications
• Window Identity Foundation (WIF) provides a
common programming model for claims
– Used by Windows Communication Foundation (WCF)
and ASP.NET applications
– Validates the incoming security token and parses the
claims that are inside
• SharePoint Services and SharePoint 2010 can
be enabled to support claims-based identity
– Configured via wizard and PowerShell
Standards and Protocols
• ADFS v 2.0 supports both active and passive
clients
– Active clients interact via web services
– Passive clients interact via browser requests
• Support for Industry standard protocols, allows
interoperability with third-party solutions
– WS-Federation
• SharePoint requires WS-Federation v 2
– SAML 2.0
Passive
Client
Claims-aware app
ADFS STS
User
Active Directory
App trusts STS
Browse app
Not authenticated
Redirected to STS
Authenticate
Return Security Token
ST
Send Token
Return page
and cookie
ST
Query for user attributes
X.509 Certificates
Relying party
Root for B
Issuer
A
Public key of C
D
Communication
B
Signing ST
C
Encyption ST
Root for A
Public key of D
• Trust is managed through certificates
• Certificates for
– HTTPS Communications
– Security token signing and encryption
• Require PKI for A & B certificates, C & D can be selfsigned by ADFS server
Federation Metadata
• During the establishment of the issuer / relying party
trust, both parties will require configuration which
includes
–
–
–
–
End-points for communication
Claims offered by issuer
Claims accepted by replying party
Public keys for signing and encryption
• This information can be manually configured or
automatically via the exchange of federation
metadata
– Federation metadata can be automatically updated
Offered Claims Types
Extract from federationmetadata.xml
<fed:UriNamedClaimTypesOffered>
<fed:ClaimType Uri="http://schemas.xmlsoap.org/claims/EmailAddress">
<fed:DisplayName>Email Address</fed:DisplayName>
</fed:ClaimType>
<fed:ClaimType Uri="http://schemas.xmlsoap.org/claims/UPN">
<fed:DisplayName>User Principal Name</fed:DisplayName>
</fed:ClaimType>
<fed:ClaimType Uri="http://schemas.xmlsoap.org/claims/CommonName">
<fed:DisplayName>Common Name</fed:DisplayName>
</fed:ClaimType>
<fed:ClaimType Uri="http://schemas.xmlsoap.org/claims/Group">
<fed:DisplayName>Group</fed:DisplayName>
</fed:ClaimType>
</fed:UriNamedClaimTypesOffered>
Installing ADFS
• Requires Windows Server 2008 / 2008 R2
– Requires IIS 7, .NET 3.5 SP1, WIF
– See deployment guide for required hot fixes and
updates
• Issue and install server certificates for HTTPS
• Download and install ADFS 2.0
– Simple Wizard
• New / farm member / Proxy – SSL cert – Names
Configuration
Claims-aware
application
Active Directory
ADFS 2.0
Define AD as
claims provider
Define STS1 as
claims provider
APP1
STS1
Define APP1 as
Relying party
• Relationships between APP1 and STS1
established through the exchange of federation
metadata
– Can be manually configured
Demo
Configuring SharePoint as a relying party
Claims Pipeline
Specify the users that are permitted
to access the relying party
input
Issuance
Authorization Rules
Permits/denies rule processing
and claims issuance
output
ST
Issuance
Transform Rules
input
Specifies claims that will be
sent to the relying party
Resulting claims added to
security token
Claims
provider
Acceptance
Transform Rules
input
Specify incoming claims that will be
accepted from the claims provider
and the outgoing claims that will be
sent to the relying party trust
Claim Rules
• Rule templates simplify the creation of rules
• Examples of rules are:
– Permit / deny user based on incoming claim value
– Transform the incoming claim value
– Pass through / filter an incoming claim
• Multiple claim rules can be specified and are
processed in top to bottom order
– Results from previously processed claims can be
used as the input for subsequent rules
Creating Rules
Condition
Issuance Statement
• A claim rule consists of two parts, condition and
issuance statement
Demo
Creating rules to allow access to
SharePoint
Custom Claims
• Capabilities of custom rules include
– Sending claims from a SQL attribute store
– Sending claims from an LDAP attribute store using a
custom LDAP filter
– Sending claims from a custom attribute store
– Sending claims only when 2 or more incoming claims are
met
– Sending claims only when an incoming claim matches a
complex value
– Sending claims with complex changes to an incoming
claim value
– Creating claims for use in later rules
Attribute Stores
• AD FS can only use Active Directory as an
identity store for authentication
• Authentication creates a token with user and
group membership details
• The claim rules can extract further attributes
from the AD and other stores
• SQL and LDAP stores are directly supported
– Additional stores can be added through custom
extensions
Claim Rule Language
The claim rule language consists of Condition => Issuance Statement
Pass through all role Claims
c:[Type == “http://schema.microsoft.com/ws/2008/06/identity/claims/role”]
 issue(claim = c);
Change the value of the Role Claim SalesStaff to Purchasers
c:[Type == “http://schema.microsoft.com/ws/2008/06/identity/claims/role”,
Value =~ “^(?i)SalesStaff$”]
=> issue(“http://schema.microsoft.com/ws/2008/06/identity/claims/role”,
Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value =
“Purchasers”, ValueType = c.ValueType)
After a claim is issued it is added to both the input and output claims
set allowing the transformed claim to be processed by subsequent rules
To make a processed claim available just for reprocessing replace the
“issue” statement with “add”
Demo
Managing Custom Rules
How do we Let Partners in?
• So far we have looked at supporting claims
aware apps within your organization
– Creating an identity (includes authentication)
framework that can be consumed by all applications
regardless of their location
– Allowing the identity token to carry more information
than just the user and group memberships
• To allow partners to access our systems we
must trust them to authenticate their users
Federated Identity
Partner organization
Your organization
Partner ADFS
STS & IP
Your ADFS
STS
Claims Trust
Claims Trust
Relying Party Trust
• Your STS now trusts your partner to
provide a security token containing claims for
their users
• Your STS is no longer responsible for identifying
the user but still processes the claims from the
partner as previously described
Relying
Party x
Summary
Your Organization ADFS
Security Token Service (STS)
Partner user
ST
ST from Partner
Claims Trust
Client request token for
access to relying party x
Trusted
Partner
ST
ST
Returns token
for Relying Party x
Processes
Acceptance
Transform Rules
Processes
Issuance
Authorization Rules
If allowed processes
Issuance
Rules
Relying
Party x
If denied
Processing ends
Passive Client
Your
Claims-aware app
Partner user
Your
ADFS STS
Partner
ADFS STS & IP
Browse app
Not authenticated
Redirect to your STS
Home realm discovery
Redirected to partner STS requesting ST for partner user
Authenticate
Return ST for consumption by your STS
ST
Redirected to your STS
Return new ST
ST
Send Token
Return page
and cookie
Process token
ST
ST
Active
Directory
Demo
Establish federation with company B
Remember the Benefits
• Claims provide a framework that can be
consumed by all applications regardless of their
location
• Allows the identity token to carry more
information than just the user and group
memberships
• Your trusted partners manage the identity and
authentication of their users
• The solution is based on industry standard
protocols
• Works for browsers and web services
What Next?
• Build a test lab and try the Microsoft ADFS stepby-step guides
– How To Set Up The AD FS 2.0 Lab Environment for
Federated Collaboration
• Hyper-V images available for download
– Federated Document Collaboration Using Microsoft
Office SharePoint Server 2007 and AD FS 2.0
• Read the ADFS Design and Deployment guides
• Read AD FS blogs
Any Questions
• Please email technical queries to:
info@xtseminars.co.uk
• Consultancy services also available
Thanks for coming to the session
See you again