Keith Brown Cofounder pluralsight.com SIA312

Outline What is identity? Challenges Federated identity How it works from a 10,000 foot view Terminology and History Steps to get started Demos!

What is Identity, for this talk? It’s whatever helps you answer these questions Who are you? What are you allowed to do? How can I personalize my app for you? Photo used under Creative Commons from cd.harrisoncd.harrison

How do you Discover Identity Today? Windows enterprise apps Windows domain accounts, Kerberos Internet-facing ASP.NET apps SqlMembershipProvider, Forms auth OpenID You name it…

Identity can be Tough Windows authentication is easy Until someone outside your domain wants to play

Identity can be Tough User/password databases are costly and painful For developers For users Photo used under Creative Commons from maca.fotomaca.foto

Identity can be Tough Single sign on So many apps do their own thing It’s often tough to achieve SSO But users sure appreciate it

Identity can be Tough The age of cloud computing is upon us How do we deal with identity in the cloud?

Pressure is Mounting for Change There’s clearly a need for change Devs are tired of implementing identity in every app Users are tired of tracking 100’s of passwords Seems like the only ones winning are the phishers

Enter Federated Identity Adds a level of indirection Don’t worry about authenticating users in your app Let an identity provider (IdP) deal with that Single sign on follows naturally

Federated Identity in the Small Identity provider Expense Reporting App Expense Reporting App Time Tracking App Time Tracking App Accounting App Accounting App WS- Federation

Federation Between Realms Easy to expand reach to other realms Apps don’t need to be changed Supports partnerships across companies Enables cross-platform access

Federation Between Realms Expense Reporting App Expense Reporting App Time Tracking App Time Tracking App Accounting App Accounting App Identity provider Identity provider Identity provider Identity provider Realm A Realm B

What gets sent to the app? Application receives a security token Created, signed, encrypted by your IdP Contains claims your IdP makes about the user Photo used under Creative Commons from WayTruWayTru

This idea isn’t new Lots of history SAML, Liberty, OpenID, etc. Active Directory Federation Services v1.NET 3.0 (WCF + System.IdentityModel) CardSpace

Step 1: Establish Trust Establish trust with your issuer Generate a cert for your app (self-signed typical) Exchange certs with issuer Photo used under Creative Commons from MiikaMiika

Step 2: Configure your Provider What do you need to know about the user? Roles Shoe size etc...

Step 3: Accept Claims in your app Geneva Framework supplies plumbing Does crypto heavy lifting for you Presents claims via IClaimsIdentity

Claims in Geneva Framework IClaimsIdentity extends IIdentity, adding claims Collection of claims Name and Role claims for backwards compatibility May include delegate chain for ActAs scenarios

Claim in Geneva Framework Key properties of Claim include: ClaimType Value, ValueType Issuer Strings avoid deserialization complexities

Where do I get an Identity Provider? Identity providers can be built or purchased Geneva Server (free with Windows Server license).NET Access Control Service (cloud-based) Build your own with the Geneva Framework

Standards Involved SAML (Security Assertion Markup Language) XML vocabulary for “security assertions” SOAP query protocol for retrieving tokens (SSO) WS-Trust SOAP protocol for retrieving tokens of any type WS-Trust and SAML protocols not wire compatible WS-Federation SSO for web services (“active” clients) via WS-Trust SSO for web apps (“passive” clients, aka browsers) using HTTP techniques

Terminology Subject The user/entity being authenticated Relying Party Any app that relies on claims Issuer, Security Token Service (STS) Authority that issues tokens STS often loosely equated to “issuer” STS is key abstraction for issuer in Geneva Fx You must derive a class from SecurityTokenService to supply claims-issuance logic

Terminology App (Relying Party) Issuer STS Issuer (identity provider) Issuer (identity provider) STS Subject and Requesto r App (Relying Party) trust

WS-Trust request security token response Web Service Issuer STS request (includes token) Service decrypts SAML token and discovers claims made by issuer

WS-Trust Q&A Requestor discovers address/binding of issuer May be hardcoded into client config May be discovered at runtime via WS-Mex and WS- Policy Requestor proves ownership of token SAML subject confirmation == “holder-of-key” Requestor signs security header with proof key Similar in spirit to Kerberos

WS-Fed (passive) part 1 Issuer Web App Initial HTTP request Web page HTTP redirect

WS-Fed (passive) part 2 Issuer Web App Web page authenticate SAML token POST SAML token auto-POST via form & javascript App decrypts SAML token and discovers claims made by issuer

WS-Fed (passive) Q&A Requestor proves ownership of token SAML subject confirmation method is “bearer” HTTPS required to foil eavesdroppers How is a logon session maintained? The SAML token POST’ed to your site is like an initial login for a user Use traditional web login techniques (cookies, typically) to start a session

Claims-based identity and Federation

Sessions On-Demand & Community Resources for IT Professionals Resources for Developers Microsoft Certification and Training Resources Microsoft Certification & Training Resources Resources Required Slide Speakers, TechEd 2009 is not producing a DVD. Please announce that attendees can access session recordings at TechEd Online. Required Slide Speakers, TechEd 2009 is not producing a DVD. Please announce that attendees can access session recordings at TechEd Online.

Complete an evaluation on CommNet and enter to win! Required Slide

© 2009 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. Required Slide