ASP.NET Single-Sign-On

Dominick Baier | thinktecturedominick.baier@thinktecture.com

http://www.thinktecture.com

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 dominick.baier@thinktecture.com

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"> dbaier@leastprivilege.com </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/

25

Contact me…

dominick.baier@thinktecture.comhttp://www.leastprivilege.com