COMP 529 - Advanced Computer Networks Single Sign-on Authentication and Pubcookie By Archie E. Huerto CSUN – COMP 529

COMP 529 - Advanced Computer Networks

Single Sign-on Authentication and

PubcookieBy Archie E. HuertoCSUN – COMP 529


Roadmap

• Taxonomy of SSO Systems

• Using SSO on Trusted Platforms

• Structured Assertion Markup

Language

• Pubcookie


Password Explosion

• Multiple passwords to access different systems weakens security

• Users will tend to pick easy to remember and therefore easy to guess passwords

• They may write down passwords in obvious places


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

• Primary Authentication - A user is authenticated through the pseudo-SSO component

• Secondary Authentication - A separate authentication occurs every time the user logged into a service provider

• The pseudo-SSO component manages service provider specific credentials, which constitute the SSO identities.


Pseudo-SSO

SSO Identities(Service Provider Specific)

Alison

Service Provider 1

Service Provder 3

Service Provider 2

[email protected][password]

Alison2001[password]

Alison[password]

X.509 certificate

Primary Authentication(e.g. Operating System Login)

Pseudo-SSO Component


True SSO

• A user is authenticated through an Authentication Service Provider (ASP)

• The ASP needs to have an established relationship with all SPs to which SSO is to be established

• The authentication process that involves the user occurs between the user and ASP

• Service providers are notified via authentication assertions which contains the user’s SSO identity and the authentication status with the ASP


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 SystemUser

Service 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 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

Kerberos• A network authentication protocol designed

to provide strong authentication for client/server applications by using secret-key cryptography

• A Kerberos server is comprised of an authentication server and a ticket granting server which acts as the ASP

• Every user and SP shares a long-term secret key with the ASP



Granting Kerberos Tickets

1. Client ASP: c

2. ASP Client: {Ks1}Kc, {Tgt}Ks1

3. Client ASP: {Ac}Ks1, {Tgt}Ks1

, SPID

4. ASP Client: {Ks2}Ks1

, {Tsg}Ks

5. Client SP: {Ac}Ks2, {Tsg}Ks



Microsoft .Net Passport• A web-based SSO service offered by Microsoft

since 1999 and is one of the widely deployed services of its kind.

• Passport accounts can store address, date of birth, and credit card details

• A unique 64-bit numeric identifier called “Passport User ID” (PUID) is assigned to user during account creation

• Users can register at the Passport home page (www.passport.com), Windows XP registration wizard, or any participating sites

http://www.passport.com/



.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)



The Liberty Alliance• A set of open specifications for web-based

SSO developed by a consortium of over 140 companies

• Based on “trust circles” formed by trusted ASPs and relying SPs

• Uses the Security Assertions Markup Language (SAML)


Roadmap




Language

• Pubcookie


Trusted Platforms

• The Trusted Computing Group (TCG) is a not-for-profit industry-standard organization with the the following goal:

“Through the collaboration of platform, software, and technology vendors develop a specification that delivers an enhanced HW and OS based trusted computing platform that enhances customer’s domains.”

• TCG was formed in Spring 2003 and has adopted the specifications developed by the Trusted Computing Platform Alliance (TCPA)


What is TCG Technology

• Trusted Platform (TP) – a computing platform that conforms to the TCG specifications

• Trusted Platform Module (TPM) – a crypto co-processor with special functionality that every TP has

• TPM is attached to the platform and cannot be removed

• Information stored in the TPM is resistant to any direct software attack, as the information can only be accessed through well-defined commands known as “TPM capabilities”


TPM Identity

Endorsement Key • A unique RSA key pair that every TPM has

imprinted in it• The private key (EKpr) never leaves the TPM• The public key (EKpu) can only be retrieved

from the TPM under certain conditions • The EK is used to decrypt information sent to

a TPM from a Privacy Certification Authority (CA)


Attestation

• The process of vouching for the accuracy of information

• Attestation Identity Key (AIK) – A special purpose asymmetric signature key

created by the TPM from its EK and used for signature generation and verification

– Every TP can have more than one AIK– The private portion of the AIK is non-migratable

and protected by the TPM– The public portion of the AIK is part of the AIK

Credential, issued by a Privacy CA– Allows a user to signify to third parties that he/she

is using a genuine TP without revealing its identity


AIK Certification Process

1. TP Privacy CA: AIKpu, EKpuThe trusted platform creates an new AIK, sends the public key of a new AIK and its public EK to a certifying authority

2. Privacy CA TP: {AIK Credential(AIKpu)}EKpubThe certifying authority after receiving it creates a certificate for the public portion of the AIK, encrypts it with the public endorsement key, and send it back to the TP

3. TP Privacy CA: AIK Credential(AIKpu)The TP then decrypt the new AIK credential and proves to the certifying authority that it was able to do so because it has the private EK


Integrity Measurement (Metrics)

• The process of obtaining metrics of platform characteristics that affect the integrity (trustworthiness) of a platform

• Platform Configuration Registers (PCRs) – a shielded location where the metrics and its digests are stored

• Measured Values – a representation of embedded data or program code

• Measurement Digest – SHA-1 cryptographic hash of measurement values

• PCR[n] SHA-1(PCR[n] + measured values)


Integrity Challenge/Response

• Integrity Challenged – issued by third party to assess the software state of a TP, includes a nonce to protect for replay

• Integrity Response– Current PCR values – Digital signature over the PCR values and

the nonce using one of the AIK– AIK Credential for the AIK used to produce

the signature


Using Trusted Platforms for SSO

• User authentication can be delegated to the user’s TP and carried out by an Authentication Service (AS) within that TP

• AIK Credentials are unique because they carry a unique serial number assigned by the issuing Privacy CA (e.g [Privacy CA, Serial Number])

• SPs can use AIK Credentials as SSO Identities for users


SSO Entities

User System• SSO Identities needs to be generated and

activated for each user of a given TP• For TPs with multiple users, the AS should allow

TPM owners to create a set of distinct SSO Identities for each user of the platform

• AS will be tightly integrated into the TP’s operating system or part of the OS login mechanism

• SPs can asses the integrity of the AS in the user’s system since it is measured in the TPM’s PCR


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


Trust Relationship

• End users needs to trust the Privacy CA chosen to certify their AIK Credentials that corresponds to SSO Identities

• SP needs to trust the Privacy CA chosen by the user to certify the AIK Credentials of their SSO Identities

• SP needs to trust the AS installed on the user TP and any software executed before the AS

• Trusting the Privacy CA means trusting TP and TPM manufacturers vouched for by the Privacy CA


Roadmap




Language

• Pubcookie


What is SAML?

• The Security Assertion Markup Language is an XML-based framework fro communicating user-authentication, entitlement, and attribute information

• It is developed by the Security Services Technical Committee (SSTC) of the Organization for the Advancement of Structured Information Standards (OASIS)

• SAML V1.0 became OASIS standard in November 2002, SAML V1.1 followed in September 2003, and SAML V2.0 in March 2005


SAML Parties

• Identity Provider (IdP) – The system that asserts information about a subject, also known as SAML authorities and Asserting Parties

• Service Provider (SP) – The system that relies on the information supplied to it by the IdP, also known as Relying Parties, local access policy defines whether the subject may access local resources


Drivers for the Creation of SAML

• Limitation of Browser cookies – Most SSO system using cookies to maintain state cannot transfer authentication between DNS domains

• SSO Interoperability – How products implement SSO and Cross-Domain SSO (CDSSO) are completely proprietary and organization must use the same SSO product in all domains


Drivers for the Creation of SAML

• Web Services – Security within Web Services is still being defined. The SAML provides the means by which authentication and authorization assertions can be exchanged between communicating parties.

• Federation – The need to simplify identity management across organizational boundaries, allowing users to consolidate many local identities into a single Federated Identity.


SAML Components

• Assertions – defined by an XML schema, it carries statements about a Principal as asserted by an Asserting Party. It could be requested or “pushed” out to the SP.

• Protocols – defined by an XML schema, it specifies how and which assertions are requested.

• Bindings – defines the lower-level communications or messaging protocols (HTTP or SOAP) that the SAML protocols can be transported over.

• Profile – contains the Assertions, Protocol, and Bindings to support a defined use case


SAML ComponentsProfiles

(Supports a defined use case)

Profiles(Supports a defined use case)

Binding(Defines how SAML protocols map onto standard

messaging or communication protocols)

Binding(Defines how SAML protocols map onto standard

messaging or communication protocols)

Protocol(Request/Response pairs for obtaining Assertions and Federation Management)

Protocol(Request/Response pairs for obtaining Assertions and Federation Management)

Assertions(Authentication, Attribute and Authorization Information)

Assertions(Authentication, Attribute and Authorization Information)


SAML Assertions

SAML defines three kinds of statements that can becarried within an assertions:• Authentication statements – issued by the party

that successfully authenticated the user. It specifies who issued the assertion, the authenticated subject, validity period, and other related authentication information.

• Attribute statements – contain specific details about the user (e.g. “Gold” status)

• Authorization decision statements – identifies what the user is entitled to do (e.g. what item he is permitted to buy)


SAML Protocols

SAML defines a number of request/response protocolsencoded in an XML schema as a set ofrequest/response pair:• Assertion Query and Request Protocol – defines a

set of queries to obtain SAML assertions.• Authentication Request Protocol – defines an

<AuthRequest> message (from SP) that causes a <Response> message to be returned (by IdP).

• Artifact Protocol – provides a way to obtain previously created assertions by a reference (i.e. artifact)


SAML Protocols

• Name Identifier Management Protocol – provides a way to change the value or format of the name of the Principal. Can be issued by either the IdP or SP. Can be used to terminate an association of a name between an IdP and SP.

• Single Logout Protocol – provides a way for near-simultaneous logout of all sessions associated to a Principal, can be initiated by the Principal or a session timeout.

• Name Identifier Mapping Protocol – provides a way to enable “account linking” or Federation.


Overview of SOAP

SOAP (Simple Object Access Protocol) is a protocol that specifies an enveloping mechanism for sending data via XML. It specifies three major XML elements:

• <Envelope> – required root document element

• <Header> – an optional element that may define some attribute about a message

• <Body> – contains the data intended for the final message recipient.


SOAP Message

POST /InStock HTTP/1.1

Host: www.stock.org

Content-Type: application/soap+xml; charset=utf-8

Content-Length: nnn

<?xml version="1.0"?>

<soap:Envelope

xmlns:soap="http://www.w3.org/2001/12/soap-envelope"

soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <soap:Body xmlns:m="http://www.stock.org/stock">

<m:GetStockPrice>

<m:StockName>IBM</m:StockName>

</m:GetStockPrice>

</soap:Body>

</soap:Envelope>


SAML Assertions StructureSOAP BodySOAP Body

SAML ResponseSAML Response

Response HeaderResponse Header

SAML AssertionSAML Assertion

Other Statements

Other Statements

AuthenticationStatement

AuthenticationStatement


SAML Assertion<?xml version="1.0" encoding="UTF-8"?><saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Version="2.0" IssueInstant="2005-01-31T12:00:00Z"> <saml:Issuer>www.acompany.com</saml:Issuer> <saml:Subject>

<saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"> [email protected]

</saml:NameID> </saml:Subject> <saml:Conditions NotBefore="2005-01-31T12:00:00Z" NotOnOrAfter="2005-01-31T12:00:00Z"> </saml:Conditions> <saml:AuthnStatement AuthnInstant="2005-01-31T12:00:00Z" SessionIndex="67775277772"> <saml:AuthnContext>

<saml:AuthnContextClassRef> urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport

</saml:AuthnContextClassRef> </saml:AuthnContext> </saml:AuthnStatement></saml:Assertion>


SOAP Over HTTP BindingHTTPHTTP

SOAP MessageSOAP Message

SOAP HeaderSOAP Header

SOAP BodySOAP Body

SAML RequestOr Response

SAML RequestOr Response


SAML AuthnRequest<env:Envelope xmlns:env=”http://www.w3.org/2003/05/soap/envelope/”> <env:Body> <samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" ForceAuthn="true" AssertionConsumerServiceURL="http://www.example.com/" AttributeConsumingServiceIndex="0" ProviderName="string" ID="abe567de6" Version="2.0" IssueInstant="2005-01-31T12:00:00Z" Destination="http://www.example.com/" Consent="http://www.example.com/" > <saml:Subject xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"> [email protected] </saml:NameID> </saml:Subject> </samlp:AuthnRequest> </env:Body></env:Envelope>


SAML Response within SOAP Message

<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" ID="abe567de6" InResponseTo="example-ncname" Version="2.0" IssueInstant="2005-01-31T12:00:00Z“ Destination="http://www.example.com/" Consent="http://www.example.com/"> <samlp:Status> <samlp:StatusCode Value="samlp:Success"/> <samlp:StatusMessage>Success</samlp:StatusMessage> <samlp:StatusDetail/> </samlp:Status> …… SAML ASSERTION AND STATEMENTS </samlp:Response> </env:Body></env:Envelope>


Generic SP-Site-First Scenario

User

ServiceProvider

IdP-4

IdP-3IdP-1 IdP-2

2: HTTP Redirect with<AuthnRequest>

1: Access Resources

3: HTTP Post with<Response>

4: Access Granted


Generic IdP-Site-First Scenario

IdentityProvider

User

2: HTTP Post withUnsolicited <Response>

1: Login

4: Access Granted

SP-2 SP-3SP-1

SP-4


Generic SSO Portal Scenario1) The unauthenticated user

accesses the unprotected portal.

2) User selects IdP-1 and SP-1 from portal. Portal redirects user to SP-1 with Idp-1 as URL parameter.

3) SP-1 gets the IdP ID from the URL and generates a SAML <AuthnRequest> to IdP-1 via HTTP redirect.

4) After a successful authentication, IdP-1 returns a SAML <Response> to SP-1.

5) User is granted access to resources in SP-1. After a while, user again returns to the portal but this time to access SP-2.

6) Portal determines user had authenticated with IdP-1 and redirects user to SP-2 with IdP-1 as URL parameter.

7) SP-2 gets the IdP ID from the URL and generates a SAML <AuthnRequest> to IdP-1 via HTTP redirect.

8) IdP-1 determines that the user is already authenticated and immediately returns a SAML <Response> to SP-2.

9) User is granted access to resources in SP-2.

IdP-1

2: HTTP Redirectwith Idp Entity ID

1: Access UnprotectedPortal

4: HTTP Post with<Response>

5: Access Granted

Web Portal

SP-1

3: HTTP Redirectwith <AuthnRequest>

6: HTTP Redirectwith Idp Entity ID

7: HTTP Redirectwith <AuthnRequest>

8: HTTP Postwith <Response>

9: Access Granted

SP-2

User


Security in SAML

• The relying party and the asserting party must have a pre-existing trust relationship, typically involving PKI

• For message integrity and confidentiality it is recommended to use HTTP over SSL 3.0 or TLS 1.0

• When an SP requests an assertion from an IdP then a bilateral-authentication is required using SSL or TLS and client-server authentication is recommended

• When pushing an assertions and request to an SP then it is mandated that the response message be digitally signed using the XML digital signature standard


Roadmap




Language

• Pubcookie


What is Pubcookie?

• Open-source package for intra-institutional SSO web authentication

• Reuses existing authentication services such as Kerberos, Microsoft’s Lightweight Directory Access Protocol (LDAP), or Sun’s Network Information Service (NIS)

• Supports Apache and Microsoft IIS• Originally developed at the University of Washington

in 1998• Made available to others in 2001 to make better web-

based SSO systems• Became an open-source project in late 2001


Pubcookie Model

Components for SSO Functionality:• User Agent - Web Browser• Pubcookie Login Server

– Central authorization service, interacts directly with users

– Verifies usernames and password with back-end authentication services

– Issues cookies to users to provide SSO functionality

– Issues cookies to application servers to provide authentication


Pubcookie Model

Components for SSO Functionality continued…• Pubcookie Application Server

– Authentication enforcer, redirects un-authenticated users to the login server

– Verifies authentication information returned from the login server

– Issues cookies to users to maintain authenticated application sessions

– Provides user authentication information to applications


Pubcookie Model

Components for SSO Functionality continued…• Authentication Service

– External component that verifies user authentication information sent to it from the login server

– Kerberos– Lightweight Directory Access Protocol (LDAP) – a

protocol based on X.500 used to access information stored in an information directory (a.k.a. LDAP directory)

– Network Information Services (NIS) - a network naming and administration system for smaller networks developed by Sun Microsystems


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


Questions?

SSO Rocks!

Documents

COMP 529 - Advanced Computer Networks Single Sign-on Authentication and Pubcookie By Archie E. Huerto CSUN – COMP 529