230 likes | 421 Views
A Claims Based Identity System. Steve Plank Identity Architect Microsoft UK. topics. phishing, phraud identity layer 7 laws human integration consistent experience across contexts Identity metasystem ip rp user identity selector non-disclosure tokens. web server.
E N D
A Claims Based Identity System Steve PlankIdentity Architect Microsoft UK
topics • phishing, phraud • identity layer • 7 laws • human integration • consistent experience across contexts • Identity metasystem • ip • rp • user • identity selector • non-disclosure tokens
web server www.identitytheft.com www.mybank.com.net.iwill.take.over.your.life.com/dodgy.php gullible@hotmail.com under the control of somebody else **************** bad person’s database
IIS Credentials database Custom Solution FormsAuthentication.SetLoginCookie() Custom Solution www.newcorp.com Application Error: Cross-domain cookie. A cookie has been received from a security domain other than the one to which this web server is a member. This is a potential security breach. Please consult the application or web server administrator. Custom Solution www.megacorp.com
Identity no consistency Naming DNS Connectivity IP
www.identityblog.com • user control and consent • minimal disclosure for a defined use • justifiable parties • directional identity • pluralism of operators and technologies • human integration • consistent experience across contexts
Human integration • Consistent experience across contexts Planky’s Card Card Collection
Identity Provider Locally installed software: not under somebody else’s control Identity Selector 1:1 relationship between cards and identity providers Subject
Identity Provider digital signature Metadata: URI of the Identity Provider Claims you can get from the IP givenname: lastname: email: user-id: etc: Intentionally left blank
Identity Provider cryptographic binding between the card and the IP digital signature
There will be many Identity Providers each running its own technology stack OR • Pluralism of operators and technologies • Human integration • Consistent experience across contexts
Identity Provider Relying Party Web Service Web Site <sp:IssuedToken ...> ... <sp:RequestSecurityTokenTemplate> ... <wst:Claims wst:Dialect=”http://schemas.microsoft.com/ws/2005/05/identity”> <ic:Claim URI=”http://.../ws/2005/05/identity/claims/givenname”/> <ic:Claim URI=”http://.../ws/2005/05/identity/claims/surname” <ic:Claim URI=”http://.../ws/2005/05/identity/claims/email”/> <ic:Claim URI=”http://.../ws/2005/05/identity/claims/privatepersonalidentifier” </wst:Claims> </sp:RequestSecurityTokenTemplate> ... </sp:IssuedToken> <object type="application/x-informationcard" name="_xmlToken"> <param name="tokenType" value="urn:oasis:names:tc:SAML:1.0:assertion" /> <param name="requiredClaims" value="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress http://schemas.xmlsoap.org/ws/2005/05/identity/claims/privatepersonalidentifier" /> </object> WS-* HTML WS-* Identity Metasystem Microsoft Identity MetaSystem WS-* HTML Subject
Relying Party Identity Selector’s Built-in Identity Provider 2 degrees of store protection: System Key Password Key Identity Metasystem Subject Personal Cards: fixed schema
personal cards what claims i make about myself fixed schema (protect the users from themselves!) managed cards what claims another party makes about me flexible schema
elvis presley only 1 of them is real probably
SECURITY TOKEN SAML Token XrML License X.509 Certificate Kerberos ticket . . . ...others Steve Plank Over 18 Over 21 Under 65 image
security token service • MEX (Metadata Exchange) endpoint • policy • how to get tokens • token service endpoint • responds to RST (Request Security Token) • delivers tokens (wrapped in RSTR (RST Response)) SECURITY TOKEN Steve Plank Over 18 Over 21 Under 65 image web service: STS give it something DIFFERENT SECURITY TOKEN Username Password Biometric Signature Certificate
identity provider relying party [ ] e [ ] s click login button get policy authenticate RST identity.provider.com requires username and password to validate this request. Enter the information below policy: uri of ip required claims optional claims token type policy: authn reqs token types ... RSTR subject
identity provider relying party [ ] [ ] Do you want to send this card to: ip.sisa.com token decryption token authentication *givenname: Steve *surname: Plank *emailaddress: planky@plankytronixx.com *privatepersonalidentitifer: planky123 real token ip.sisa.com ip.sisa.com subject display token
... but the IP could tell lies! • real token might be opaque • how to inform the subject? real token subject display token
Non-disclosure tokens Steve Plank splank@microsoft.com Authenticity Signature DOB: 17-Jun-59 • stefan brands • credentica u-prove • acquired 6th march 2008 • privacy
review www.identityblog.com • phishing, phraud • identity layer • 7 laws • human integration • consistent experience across contexts • Identity metasystem • ip • rp • user • identity selector • non-disclosure tokens