Active Directory Federation Services How does it really work? John Craddock johncra@xtseminars.co.uk

John Craddock Created by John Craddock, XTSeminars Ltd brings you world class IT seminars written and delivered by experts. As an infrastructure and security architect he has designed and implemented global distributed IT solutions, providing services to industry leaders including Microsoft. John is an international speaker, delivering technical seminars, sessions and keynotes around the world and is a featured speaker at major IT conferences such as Microsoft TechEd. John Craddock can be engaged as a consultant by contacting him directly: 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 co-locates the organisation’s AD directory Your DCs are hosted in the Microsoft datacentre

Allowing Access by Partners Partner organization Your Organization 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

Federation of Identity The Solution Federation of Identity Many players in the game… Microsoft solution Active Directory Federation Services The latest release AD FS v 2.0

Key Concepts Issuer Identity Provider (IP) Security Token Service (STS) User / Subject /Principal Authentication request Active Directory Issues Security Token ST 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 Security Token “Authenticates” user to the application Relying party / Resource provider Trusts the Security Token from the issuer Signed by 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 User Claims-aware app ADFS STS Active Directory App trusts STS Browse app Not authenticated Redirected to STS Authenticate Return Security Token ST Query for user attributes Send Token ST Return page and cookie

X.509 Certificates Trust is managed through certificates Relying party Issuer Root for B A Communication B Root for A Public key of C Signing ST C D Encyption ST 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 self-signed 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 Uri="http://schemas.xmlsoap.org/claims/CommonName"> <fed:DisplayName>Common Name</fed:DisplayName> <fed:ClaimType Uri="http://schemas.xmlsoap.org/claims/Group"> <fed:DisplayName>Group</fed:DisplayName> </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 Active Directory Claims-aware application ADFS 2.0 Define STS1 as claims provider Define AD 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 Claims provider Specify the users that are permitted to access the relying party input input Issuance Authorization Rules Acceptance Transform Rules Specify incoming claims that will be accepted from the claims provider and the outgoing claims that will be sent to the relying party trust Permits/denies rule processing and claims issuance output input Issuance Transform Rules ST Specifies claims that will be sent to the relying party Resulting claims added to security token

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 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 from Partner Trusted Partner ST ST Claims Trust Client request token for access to relying party x Relying Party Trust ST Processes Acceptance Transform Rules Relying Party x ST Returns token for Relying Party x Processes Issuance Authorization Rules If denied Processing ends If allowed processes Issuance Rules

Passive Client ST ST ST ST Active Directory Your Claims-aware app Your ADFS STS Partner ADFS STS & IP Partner user 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 ST Redirected to your STS Process token Return new ST ST Send Token ST Return page and cookie

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 step-by-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 info@xtseminars.co.uk Please email technical queries to: Consultancy services also available info@xtseminars.co.uk

Thanks for coming to the session See you again