und Dominick Baier Unterstützung und Consulting von Software-Entwicklern
und –Architekten im Windows- und .NET-Umfeld– Entwickler-Coaching und –Mentoring– Architektur-Consulting und –Prototyping– Architektur- und Code-Reviews
Fokus auf verteilte Anwendungen, Service-Orientierung, Workflows, Cloud Computing, Interoperabilität, Security, End-to-End-Lösungen– Windows Server, .NET, WCF, WF, MSMQ, .NET Services,
Windows Azure
http://www.thinktecture.com http://www.leastprivilege.com [email protected]
2
3
Agenda
• What‘s Single Sign-On?• How does HTTP based authentication work?• ASP.NET Forms Authentication• Protocols for third party authentication• Microsoft „Geneva“ Framework for ASP.NET• Dangers of Single Sign-On
4
Single Sign-On
• The problem– many (historical) applications– username/password authentication– different account stores
• The desire– no need for separate accounts
• at least same credential for all apps– only sign-in once (a day)
5
Single Sign-On v0.5
• Unified user account data store– pre-requisite for moving on– still separate sign-on processes
6
Challenge/response based authentication
GET /default.aspx
401 / WWW-Authenticate
GET / WWW-Authorize …
7
Redirect/cookie based authentication
GET /default.aspx
302 -> login.aspx
POST /login.aspx
Set-Cookie
8
ASP.NET Forms Authentication
www.domain.com.domain.com
9
Forms Authentication scenarios
www.domain.com/app1www.domain.com/app2
app1.domain.com app2.domain.com
10
Forms Authentication drawbacks
• ASP.NET encrypts and signs authentication cookies– uses random key by default– must set a shared key in all applications
• Authentication logic must be duplicated– Forms Authentication does not support redirects outside of the
current application• Cookie domains are limited
– applications in different domains cannot „federate“
11
Forms Authentication non-scenarios
www.domain1.com www.domain2.com www.login.com
12
„Third party authentication“ protocols
• Protocols with focus on– factoring out and centralizing authentication logic– transmitting authentication tokens over domains boundaries
• Several popular standards– OpenID– SAML 2.0p– WS-Federation
13
General idea
Client Relying Party
IdentityProvider
1
2
Trust
data exchange
14
A look into a (SAML) token
<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" issuer="http://www.login.com">
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#" /></saml:Assertion>
<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" issuer="http://www.login.com">
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#" /></saml:Assertion>
<saml:Conditions> NotBefore, NotOnOrAfter, ApplicationName </saml:Conditions>
<saml:AttributeStatement>
</saml:AttributeStatement>
<saml:Attribute AttributeName="name"> dominick </saml:Attribute>
<saml:Attribute AttributeName="email"> [email protected] </saml:Attribute>
15
WS-Federation
1: GET /default.aspx
2: GET /sts/auth.aspx
<form method="POST" action="http://app/default.aspx"> <input name="wresult" value="[token]" /> … <script > window.setTimeout('document.forms[0].submit()', 0); </script></form>
<form method="POST" action="http://app/default.aspx"> <input name="wresult" value="[token]" /> … <script > window.setTimeout('document.forms[0].submit()', 0); </script></form>
3: POST /default.aspx
16
„Geneva“ project
• ADFS 2– Active Directory integrated identity provider– enterprise level management features
• Windows Identity Foundation (WIF)– extensions to .NET identity & authorization infrastructure– direct ASP.NET & WCF integration– supports writing relying parties & identity provider– token handling toolkit
http://www.microsoft.com/geneva
17
WS-Federation configuration
18
Geneva extensions to IPrincipal
interface IClaimsPrincipal : IPrincipal{ ClaimsIdentityCollection Identities { get; }}
interface IClaimsPrincipal : IPrincipal{ ClaimsIdentityCollection Identities { get; }}
interface IClaimsIdentity : IIdentity{ ClaimCollection Claims { get; } string NameClaimType { get; } string RoleClaimType { get; }}
interface IClaimsIdentity : IIdentity{ ClaimCollection Claims { get; } string NameClaimType { get; } string RoleClaimType { get; }}
interface IPrincipal { IIdentity Identity { get; } bool IsInRole(string roleName);}
interface IPrincipal { IIdentity Identity { get; } bool IsInRole(string roleName);}
interface IIdentity{ bool IsAuthenticated { get; } string AuthenticationType { get; } string Name { get; }}
interface IIdentity{ bool IsAuthenticated { get; } string AuthenticationType { get; } string Name { get; }}
19
Claim
public class Claim{ public virtual string ClaimType { get; } public virtual string Value { get; } public virtual string Issuer { get; }
// rest omitted}
public class Claim{ public virtual string ClaimType { get; } public virtual string Value { get; } public virtual string Issuer { get; }
// rest omitted}
20
Identity provider
• Normal ASP.NET application• Token issuance logic implemented in a SecurityTokenService
derived class• Token service hosted on .aspx page using a web control
SecurityTokenService
<idfx:FederatedPassiveTokenService />
issue.aspx?wa=wsignin1.0… HTTP Form POST
issue.aspx
21
SecurityTokenService
public class MyTokenService : SecurityTokenService{ protected override Scope GetScope( IClaimsPrincipal principal, RequestSecurityToken request) { // parse request.AppliesTo (and return encryption cert) }
public override IClaimsIdentity GetOutputClaimsIdentity( Scope scope, IClaimsPrincipal principal, RequestSecurityToken request) { // retrieve claims from store and return them as IClaimsIdentity }}
public class MyTokenService : SecurityTokenService{ protected override Scope GetScope( IClaimsPrincipal principal, RequestSecurityToken request) { // parse request.AppliesTo (and return encryption cert) }
public override IClaimsIdentity GetOutputClaimsIdentity( Scope scope, IClaimsPrincipal principal, RequestSecurityToken request) { // retrieve claims from store and return them as IClaimsIdentity }}
22
Dangers of Single Sign-On
• Identity Provider becomes attractive target for attacks– phishing, spoofing– use SSL (and token level encryption)
• Users get access to several applications with a single credential– this credential must be secured
• Cross Site Request Forgery becomes a big issue
23
Summary
• Single Sign-On can simplify the user experience• The less credentials a human has to manage, the better• ASP.NET has limited built-in support• Special protocols needed to enable advanced scenarios• Geneva is Microsoft‘s library for federation with ASP.NET• Single Sign-On also has some issues
24
Resources
• „Developing more-secure ASP.NET Applications“– http://tinyurl.com/AspNetSecurity
• OpenID for .NET– http://code.google.com/p/dotnetopenid/
• Thinktecture Starter STS– StarterSTS.codeplex.com
• Geneva Framework Whitepaper– http://tinyurl.com/GenevaWhitepaper
• Cross Site Request Forgery (CSRF)– http://www.owasp.org/index.php/Cross-Site_Request_Forgery
• AntiCSRF– http://AntiCSRF.codeplex.com/
Top Related