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!
Download ReportTranscript 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!
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.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.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 Time Tracking App Accounting App 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 Realm A Identity provider Realm B Identity provider Expense Reporting App Time Tracking App Accounting App 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 WayTru 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 Miika Step 2: Configure your Provider What do you need to know about the user? Email 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 Issuer (identity provider)STS trust Issuer STS trust Subject and Requesto r App (Relying Party) App (Relying Party) App (Relying Party) WS-Trust Issuer STS request (includes token) Web Service 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 WSPolicy 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 page HTTP redirect Initial HTTP request Web App WS-Fed (passive) part 2 Issuer Web page auto-POST via form & javascript POST SAML token Web App 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 Resources www.microsoft.com/teched www.microsoft.com/learning Sessions On-Demand & Community Microsoft Certification & Training Resources http://microsoft.com/technet http://microsoft.com/msdn Resources for IT Professionals Resources for Developers www.microsoft.com/learning Microsoft Certification and Training Resources Complete an evaluation on CommNet and enter to win! © 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.