SSO With The WSO2 Identity Server

Suresh AttanayakeSoftware Engineer

About WSO2

• Providing the only complete open source componentized cloud platform

– Dedicated to removing all the stumbling blocks to enterprise agility– Enabling you to focus on business logic and business value

• Recognized by leading analyst firms as visionaries and leaders– Gartner cites WSO2 as visionaries in all 3 categories of applica-

tion infrastructure– Forrester places WSO2 in top 2 for API Management

• Global corporation with offices in USA, UK & Sri Lanka– 200+ employees and growing

• Business model of selling comprehensive support & mainte-nance for our products

150+ globally positioned support customers

Previous : A Walk Through SSO

● Problems with traditional authentication

● How SSO solves those problems

● Need for Open Standards

● Introduction to some open standards and how they solve the common authentication problems

What we cover today

● OpenID

● SAML 2.0 Web Browser SSO

● WS- Trust

● Solutions

● Demos

OpenID

● Sign into multiple websites with the accounts you already have.

– No need for new account creation

– Websites don't have to store passwords

● Users passwords are never shared with the websites.

● Users can decide what information to be shared with the websites dynamically

● Decentralized identity management

Entities

● OpenID Provider (OP)

– Central Authentication Service

● Relying Party (RP)

– Web Applications

● User Agent

– Web Browser

● User

OpenID Providers

OpenID Identifiers

● Google

– https://profiles.google.com/YourGoogleID

● Blogger

– http://blogname.blogspot.com/

● MySpace

– http://www.myspace.com/username

Relying Parties

Relying Parties

● Over 50,000 web sites

– http://wiki.openid.net/w/page/25453698/Gallery

● One billion user accounts

● Drupal, Wordpress and libraries

● Visit http://openid.net/

OpenID

OpenID Authentication

1. User enters the OpenID Identifier and clicks login at the Relying Party (RP).

2.RP performs discovery on the provided identifier.

3.RP creates an association with the OpenID Provider (OP).

4.RP issues an Authentication Request to OP.

5.OP authenticates the user.

6.OP sends an Authentication Response to RP.

7.RP validates the authentication response.

8.RP grants or denies the access to the user.

Discovery

● The Process : The relying party uses the user supplied identifier to look up necessary information to initiate the OpenID protocol

● Information

– Version

– OP endpoint URL

– Claimed ID

● Discovery methods

– XRI Resolution

– Yadis

– HTML-Based recovery

Associations

● Process : Sharing a secrete (MAC key) between the OpenID Provider and the Relying Party

● Association Types

– HMAC-SHA1

– HMAC-SHA256

● Association Session Types

– no-encryption

– DH-SHA1

– DH-SHA256

Authentication Request

● Contains

– Claimed ID

– Association handle

– Return to URL

– More

– Extensions (Attributes)

Authentication Request

Authentication Response

● Contains

– OP Endpoint

– Claimed ID

– Signature

– More

– Extensions (Attributes)

Authentication Response

Attribute exchange

● OpenID Attribute Exchange

● OpenID Simple Registration

OpenID Demo with the WSO2 Identity Server

Example Solution – Multiple Domains

What OpenID is lacking

● Single Logout

● IDP initiated SSO

● Not utilizing SSL/TLS

SAML 2.0 Web Browser SSO Profile

Entities

● Identity Provider (IDP)

– Single Sign On Service

● Service Provider (SP)

– Assertion Consuming Service

● Principle

SAML Web Browser SSO Profile

Profile Overview

1.User agent access a Service Provider.

2.Service Provider determines the Identity Provider.

3.Service Provider issues an <AuthnRequest> message to the Identity Provider.

4. Identity Provider identifies the Principle.

5. Identity Provider issues a <Response> message to the Service Provider.

6.Service Provider grants or denies the access to the Principle.

Identity Provider Discovery

● Implementation dependent

– Configuration

– Identity Provider Discovery Profile

<AuthnRequest> message

<AuthnResponse> message

Bindings

“Mapping of SAML request-response message exchange onto standard message or communication protocols are called SAML protocol bindings. ”

– HTTP Redirect Binding

– HTTP POST Binding

– HTTP Artifact Binding

Single Logout Profile

1.Service Provider issues a <LogoutRequest>.

2.Identity Provider determines Session Participants.

3. Identity Providers issues <LogoutRequest> to Session Participants.

4.Session Participants send <LogoutRespone> to the Identity Provider.

5. Identity Provider send a <LogoutResponse> to the Single Logout initiator Service Provider.

Single Logout Profile

SAML 2.0 Web Browser SSO Demo with the WSO2 Identity Server

Example Solution - Federation

What is not interesting about SAML 2.0 Web Browser SSO

● Its XML based

– serialization required

● Cryptographic operations

– Nightmare for scripting languages

WS- Trust

WS-Trust Security Model

● Web Service require set of claims to be in the incoming request message.

● If the incoming request message doesn't contain the required claims, then the service should reject or ignore the request.

● Built with

– Claims

– Policies

– Tokens

WS- Trust

Security Token Service

● Issuing tokens

● Renewing tokens

● Validating tokens

● Token exchange

● Broker trust

Tokens

● X509 public certificates

● XML based tokens (SAML)

● Kerberos shared-secrete tokens

● Digest passwords

<wst:RequestSecurityToken>

<wst:RequestSecurityTokenResponse>

WS-Trust Demo with the WSO2 Identity Server

Example Solution – Token Exchange

Example Solution – Bridged SSO

Questions?

Thank you