Linus Joyeux Valerie Alonso Managing consultantLead consultant blue-infinity (Switzerland) Active Directory Federation Services v2 branding.technology.integration in brief employees headquartered in Geneva founded in 1995 international culture multi-national clients integrated solutions Why federation Which protocols How does ADFS work demo Which applications and how demo How does that work in the cloud demo Agenda 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 Without a VPN, DirectAccess or authentication proxy solution Kerberos fails Requires developers to use a different authentication model Kerberos, NTLM, Basic, Digest, Forms? 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 organisations 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 partners 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 partners users need to remember yet another password Federation of Identity 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 Active Directory Federation Services ADFS 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 Key tec concepts Identity Provider (IP) Active Directory Security Token Service (STS) User / Subject /Principal Authentication request Issues Security Token Relying party / Resource provider Issuer Trusts the Security Token from the issuer The Security Token Contains claims about the user For example: Name Group membership User Principal Name (UPN)address of useraddress of manager Phone number Other attribute values Security Token Authenticates user to the application ST 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 organizations users or users from trusted partners Passive Client ADFS STS Claims-aware app Active Directory Browse app Not authenticated Redirected to STS Authenticate User Query for user attributes Return Security Token Return page and cookie Send Token ST App trusts STS X.509 Certificates 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 Communication A Signing Relying partyIssuer ST Encryption ST B Public key of C C Public key of D D Root for ARoot for B 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 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 Relationships between APP1 and STS1 established through the exchange of federation metadata Can be manually configured Claims-aware application ADFS 2.0 Active Directory Define AD as claims provider APP1 Define STS1 as claims provider STS1 Define APP1 as Relying party Configuring SharePoint Server as a relying party demo Claims Pipeline Issuance Authorization Rules Claims provider Specify incoming claims that will be accepted from the claims provider and the outgoing claims that will be sent to the relying party trust Specifies claims that will be sent to the relying party Acceptance Transform Rules input Issuance Transform Rules output Specify the users that are permitted to access the relying party ST Resulting claims added to security token Permits/denies rule processing and claims issuance input 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 A claim rule consists of two parts, condition and issuance statement Condition Issuance Statement Creating rules to allow access to SharePoint demo 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 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 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 Claims Trust Relying Party x Relying Party Trust Claims Trust Your ADFS STS Partner ADFS STS & IP Relying Party Trust Partner organization Your organization Process token Home realm discovery ST Redirected to partner STS requesting ST for partner user Return ST for consumption by your STS Return new ST ST Passive Client Cloud config Your ADFS STS Your Claims-aware app Active Directory Partner user Partner ADFS STS & IP Redirected to your STS ST Authenticate Send Token Return page and cookie Browse app Not authenticated Redirect to your STS Access from the cloud demo 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 servicesstep-by-step-guides(WS.10).aspx 2011 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.