MSDN Webcast: Windows Communication Foundation Top to Bottom (Part 11 of 15) - Federated Security
This series is being presented by Michele Leroux Bustamante (Chief Architect, IDesign Inc, Microsoft Regional Director for San Diego, MVP XML Web Services) and author of Learning WCF (O'Reilly, 2007) and touches on the fundamentals and practical approaches of WCF development.
This session covered:
- Underlying claims-based support in WCF
- Reasons to move toward a claims-based security model
- Steps to adopting claims-based security
- How security token services (STS) supports federated security models
- The relationship to federated security and security tokens that carry claims
Key points from this session:
- Limitations of role-based security
- Insufficient
- Roles change
- Permissions granted to roles change
- Not all credentials can be mapped to roles
- Better to base authorisation on permissions, not roles
- Permissions should not change
- Establish permissions required for features
- Associate permission demands with features
- Can add new permissions for new features
- Not built in, nor is it always enough, nor are permissions guaranteed
- Benefits of claims-based security
- Richer than permissions
- Carry information about
- User identity
- Roles or permissions
- Other useful information about the user
- Guaranteed by their issuer
- If issuer is trusted, claims are trusted
- WCF identity model is claims-based
- Credentials sent as security tokens
- Security tokens are mapped to claims
- Claims are accessible through the ServiceSecurityContext for the request
- One or more claim sets may be granted
- Multiple security tokens
- Multiple authorisation policies
- Security tokens, claims, and claim sets
- Security tokens
- Are a serialized representation of a set of authentication credentials
- Usually binary or XML
- Usually signed to guarantee authenticity
- Serialized in security headers of a SOAP message, can be interoperable
- Claims
- Describes an individual right or action
- Identity claim
- Can represent a Windows or X.509 token, a username, or another type of identity
- Proof of Possession Claim
- Can represent additional information such as e-mail address, first and last name, birth date. etc
- Can be custom application claims
- Claim sets
- Collection of claims by a particular issuer
- System issuer for Windows and X.509
- ASP.NET issuer for membership provider
- CardSpace issuer for self-signed tokens
- Security token services (STS) or custom authorisation policies
- Claim sets get generated from security tokens
- Claims authentication and authorisation
- Security principle attached to the request is still role-based
- IPrincipal type created by role
- WCF 1.0 does not have built-in claims authentication
- Why use claims-based authorisation
- Useful for issued tokens
- SAML tokens carry claims
- Normalizing authentication of multiple credential types
- Delegation of authentication to STS
- Issuance of application claims for rich authorisation
- Federation scenarios with STS
- Can decouple authentication and authorisation from applications and services
- Better performance on Web and application servers
- Greater flexibility with authentication
- Ability to use claims-based authorisation checks or delegate checks to another service
- Security token services (STS)
- A.K.A. identity provider or token issuer
- SAML tokens contain a set of claims
- Granted by token issuer
- Signed by token issuer
- Session Summary
- Claims-based security is built into WCF
- Some work required to leverage
- Normalization claims can be performed with
- Custom IAuthorizationPolicy
- Delegated to STS using WSFederationHttpBinding
- Federated security model supports single sing-on and claims authorisation
- Custom STS, ADFS vNext, PingTrust
This webcast is available for download from here along with a copy of the Powerpoint deck. The next Webcast (session 12) is scheduled for 29th August 2007 and is titled "Reliable Messaging". A schedule on the complete series can be found here.