Embed Size (px)
Citation preview
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 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
Your OrganizationPartner organization
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
• Many players in the game…• Microsoft solution– Active Directory Federation Services
• The latest release AD FS v 2.0
Federation of Identity
Key Concepts Identity Provider (IP)
ActiveDirectory
Security Token Service (STS)
User / Subject /Principal Authentication request
Issues Security Token
Relying party /Resource provider
Issuer
Trusts the Security Tokenfrom the issuer
The Security TokenContains claims about the userFor 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
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 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 ClientADFS STSClaims-aware app Active Directory
Browse app
Not authenticated
Redirected to STS Authenticate
User
Query for user attributesReturn Security Token
Return pageand cookie
Send Token
ST
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
CommunicationA
Signing
Relying party Issuer
ST
EncyptionST
B
Public key of C C
Public key of DD
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
Offered Claims TypesExtract 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
• Relationships between APP1 and STS1 established through the exchange of federation metadata– Can be manually configured
Claims-awareapplication
ADFS 2.0 Active Directory
Define AD as claims provider
APP1
Define STS1 as claims provider
STS1
Define APP1 as Relying party
Demo
Configuring SharePoint as a relying party
Claims Pipeline
IssuanceAuthorization Rules
Claimsprovider
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
AcceptanceTransform Rules
input
IssuanceTransform 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
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
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 Purchasersc:[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
• 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
RelyingParty x
Relying Party Trust
Claims Trust
Your ADFSSTS
Partner ADFSSTS & IP
Relying Party Trust
Partner organization Your organization
SummaryPartner user
Client request token for access to relying party x
Your Organization ADFS
Claims Trust
Relying Party Trust
RelyingParty x
ProcessesAcceptance
Transform Rules
ProcessesIssuance
Authorization Rules
If allowed processesIssuance
Rules
STReturns tokenfor Relying Party x
If denied Processing ends
Security Token Service (STS)
ST from PartnerSTST Trusted
Partner
ST
Process token
Home realm discovery
ST
ST
Redirected to partner STS requesting ST for partner user
Return ST for consumption by your STS
Return new ST
ST
Passive ClientYour
ADFS STSYour
Claims-aware app
ActiveDirectory
Partner user
PartnerADFS STS & IP
Redirected to your STS
ST
Authenticate
Send Token
Return pageand cookie
Browse app
Not authenticated
Redirect to your STS
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
• Please email technical queries to:
• Consultancy services also available
Thanks for coming to the sessionSee you again
