Lecture 10 Single Sign-On systems

What is Single Sign-on?

• Lets users authenticate themselves once and access different applications without re-authentication

• Increases the usability of the network

• Centralizes the management of relevant system parameters

• Two main type of SSO Systems: Pseudo-SSO and True-SSO

Pseudo-SSO

SSO Identities(Service Provider Specific)

Alison

Service Provider 1

Service Provder 3

Service Provider 2

alison@csun.edu[password]

Alison2001[password]

Alison[password]

X.509 certificate

Primary Authentication(e.g. Operating System Login)

Pseudo-SSO Component

True SSO

SSO Identities(uniform)

Alison

Service Provider 1

Service Provder 3

Service Provider 2

xRtC3Pqv02w

3HqKTXrtCo7

a32RsQ94IKf

Authentication(e.g. Operating System Login)

ASP Component

Generic SSO System

UserService Provider

ASP/Pseudo-SSOcomponent

1: Authenticaion

2: Service Request

3.1 Request

3.2 Response3: Identity

Establishment

4: Service Provision

Categories of SSO Systems

• SSO architectures can be further categorized based on the location of the Authentication Service Provider ASP/pseudo-SSO component

• It can be local to the user platform or offered as a service by an external entity (SSO proxy)

• Four Main Categories of SSO Systems– Local Pseudo-SSO– Proxy-Based Pseudo-SSO– Local True SSO– Proxy-Based True SSO

Examples of True SSO

.Net Passport User(Browser)

.Net Passport Participating Site (SP)

.Net PassportServer

1: Request Resource

2: Redirect (SPID, URLreturn)

6: Writes {Tgt}Km Cookie and Redirect to URLreturn with {Tsg}Ks

5: Submit Credentials

4: Request Credentials (username, password)

8: Writes {Tsg}Ks as Cookie

7: Return to Site with {Tsg}Ks in packet

3: Sends (SPID, URLreturn)

SSO Entities

Service Providers

• Need to verify the AS using an Integrity Challenge/Response session which also provides user identification

• Must have a well-known, human-readable unique identifier (e.g. URI) for users to authenticate SPs before releasing Integrity Response

Is SSO the Saint Graal?

Apparently not!

SSO – 8 Unsolved Problems• SSO demands Federated-Trust

– Multi-dimensional problem of administration domains• SSO Amplifies staff changes and escalates Roles

– Client changes become server overheads• SSO leads to Information Mismanagement

– Servers learn about client organization• SSO is Unresponsive to Organization Needs

– Delegation consistency is hard to arrange or Revoke• SSO Governance leads to loss of Policy Control

– ID and Password abuse and data inconsistency• SSO increases Ambient Authority risks

– All of a ‘principals’ domain authorities are exposed to attack• SSO Distributed Management limits scale

– Unsynchronized updates lead to service failures• SSO System Improvements are resisted

– Complexity lock down Federated evolution

SSO - The Simple Case• One on One

– Clients must first provide Services – With the URL for the Client’s SSO service– Client’s public key for service to verify SAML responses

SSO - The Realistic Case

• Domains have their own rules – For principles

• To Sign On• To Transfer to eBay• To Check PayPal

– Access Policy issues• Face Book based on

Originator• How about eBay and

PayPal?– Originator or what?

– What about Your Bank?• Trust is doubtful!• The Originator or some

3rd Party Intermediary

• Who decides?– Not you!

Domain

FaceBook

1

2

3

4

5

6

7

Corporation

1

2

3

4

5

6

7

1

2

3

4

5

6

7

eBay

1

2

3

4

5

6

7

PayPal

1

2

3

4

5

6

7Branch

1

2

3

4

5

6

7

BankAccount

1

2

3

4

5

6

7

Like You

Like…

Federated Identity Management

• Managing Identities is hard– Access Control List synchronization

• Federating Identities is worse– Every client adds to the cost of service– This negative feedback limits growth

• How can a domain control access?– Look up policy by identity– Who is the real Identity?– Access is based on the policy– Access Control Lists set to match

• If Access Policy is defined – Then use a Capability Pattern – Convey policy with the identity– Certify Access rights to a service– Chained to Some Method on an Object

Trusted

Partner

SAML

PolicyIdentity Policy

Policy Management Options

• IBAC– Client change are Server

problems!• Services authorize IDs

– ALC set for roles/identities • Know all users and rights• Update as users change

– Many service partners• Many more identities• Third party mashups

– Scalability is THE problem

• ZBAC– Client Changes are only Client

problem!• Service sells Access

contracts– Capabilities to service

• As access to a contract– Clients manage them

• Distribute by roles– A capabilities for a contract

• Include ways to revoke– Scalability is possible

Authorization-Based Access Control for the Services OrientedArchitecture Alan H. Karp, HP Laboratories Palo Alto

• The essential difference between these two alternative is the architecture and location of Identity Policy Control

• Is it on the service side or on the client side.• Just a small change in thinking makes a big change in

results.• When ACL Policy is managed by a service it can not

scale as a secure application• SOA and SAML are going to make things worse• Think of capabilities as secure abstractions (paper

money to gold)• They can be feely exchanged by the population but

protected by the system

IBAC Example UC1. Client sends a Signed Contract to

corporate!2. Manager sends a service-request to client.3. Client approves user to corporate. 4. Corporate sends site-credentials to

manager.5. Manager sends Work-requests to work site.6. Work site sends credentials to manager.7. Manager sends service account to work

site.8. Manager sends credentials to corporate.9. Manager sends staff-request to client. 10. Client approves identity at corporate.11. Corporate returns credentials to staff.12. Staff sends Work-request to work site.13. work site returns work-credentials to staff.14. Staff loads Work to the work site.15. Staff loads work-credentials at corporate.16. Staff sends Work request to service.17. service requests Work at work site.18. work site sends Work to the service.19. service sends Job-result to staff.

~50%ManagementOverhead

Initial Sign-on Process

User Agent(Browser)

ApplicationServer

LoginServer

AuthenticationServer

1: Request Resource

2: Redirect Page

5: Submit Login Form

6: Verify

4: Login Form

3: Granting Request

10: Response

9: Re-request

8: Redirect Page with Granting Reply

7: Response

Key Management

• Uses shared symmetric keys to encrypt messages sent between application servers and the login server

• Keys are generated and maintained by the “keyserver” application running on the login server

• Keys are negotiated and distributed using the “keyclient” utility during the setup phase of each application server

• Keys can be revoked at the login server, but automated expiration and renewal process are not yet provided

References• http://iamsect.ncl.ac.uk/dissemination/iss/iss-shib-sans-getis.ppt• https%3A%2F%2Fwww.owasp.org%2Fimages

%2F2%2F26%2FOWASPSanAntonio_2006_08_SingleSignOn.ppt&ei=vBvvTpbfDMHT4QTZlpWdCQ&usg=AFQjCNFV7y-o315tnzw2KueaP812joxAfQ&cad=rja

• http://www.esat.kuleuven.be/cosic/seminars/slides/SSO.pdf• http://www.slideshare.net/HitachiID/integrating-password-management-with-enter

prise-single-signon• http://www.cse.fau.edu/~security/public/docs/Federated%20identity%20manage

ment%20vs.%20federated%20access%20management.ppt• http://www.csun.edu/~andrzej/COMP529-S05/presentations/6.ppt• http://www.tdwg.org/fileadmin/2007meeting/slides/

Suhrbier_Shibboleth_abs187.ppt• http://www.metromidrange.org/PastMeetings/downloads/EIM-SSO

%20Overview.ppt • http%3A%2F%2Fwww.rsc-ne-scotland.ac.uk%2Fmcshib%2FPresentations

%2Fmchsib-apr08-shib2.ppt&ei=eSYDT-C8MKbm4QTCovmUDQ&usg=AFQjCNGmz4TujYs2c-9LJu0aWq7u-XczAg&cad=rja

• http://cnav.gettysburg.edu/portal/portal07/PostConference/technical/SSO3-HalfwayThere.ppt

• http://www.terena.org/activities/eurocamp/march05/slides/day2/introshib.ppt• http://www.terena.org/activities/eurocamp/nov05/slides/day2/sso.ppt

Keep on dreaming… that you are secure!