For System Integrators The Connect2id mantra Your users Your UIs / - - PowerPoint PPT Presentation

For System Integrators

The Connect2id mantra

Your users Your UIs / UX Your rules Your premise / cloud

You are in control

Top integration concerns of enterprises

authz logic

+ shape explicit / implicit consent + ID / access token processing + custom token data

claims sources

+ plug-in any data source + DB and / or web service backends + aggregation from N sources

IdP federation

+ SAML + social logins + legacy 3rd party needs

user authentication

+ plug-in any factor + choose factor based on context + feed attributes into ID token Based on our experience

Focus on web-based integration

Connect2id server web APIs for:

• Login and admin UIs
• Plug in of auth factors
• Plug in of authZ rules
• Managing the complete

token and authZ lifecycle

• Managing user sessions
• Monitoring and stats

Web-based integration enables you to leverage existing IT resources

How to customise your Connect2id server?

Modifying the server code is never needed

Use the available web APIs and Java SPIs

Server endpoints + interfaces

discovery JWK set client registration token token inspection + revocation authz store direct authz authz session session store claims source SPI userinfo grant handler SPIs:

• password
• client credentials
• SAML 2.0 bearer
• JWT bearer

monitoring

Connect2id server

OpenID Connect provider + OAuth 2.0 server

Server endpoints + web APIs

Standard endpoints

Standard OpenID Provider (OP) and OAuth 2.0 Authorisation Server (AS) endpoints:

• Discovery – metadata about the OP / AS
• Public JWK set – the public RSA and EC keys to verify tokens issued by the OP

/ AS

• Client registration – to add, update or delete clients; supports open, pre-

authorised and managed registration

• Authorisation – for end-user authentication and consent
• Token – for receiving ID, access and / or refresh tokens in exchange for a code,

password, client credentials, JWT or SAML 2.0 grant

• Token inspection – lets resource servers inspect access tokens
• Token revocation – lets clients revoke tokens and associated authorisations
• UserInfo – releases consented claims about the end-user to clients

Integration endpoints

Web-based (REST+JSON) endpoints:

• Authorisation session – plug-in a login UI, user authentication factors and consent logic at the

OAuth 2.0 authorisation endpoint; federate SAML, social logins and legacy 3rd party IdPs

• Direct authorisation – obtain ID and access tokens directly; implement token exchange
• Session store – query, monitor and administrate existing user sessions
• Authorisation store – query, update and revoke authorisations, inspect tokens
• Monitoring – back-end health-checks, 100+ server metrics

Java Service Provider Interfaces (SPI), permit web-service adapters:

• Claims sources – retrieve ID token / UserInfo claims from one or more data sources
• Grant handlers – plug in your own logic for handling:

– password grants – client credentials grants – SAML 2.0 and JWT bearer assertions

Sign-in experience

Login

User Password

alice xxxx

Consent

Allow Wonderland App access to your : email

☑

profjle

☒

deny

Allow Design your own user experiences around login and consent

Sign-in UI, auth and authz

• When a client app wants to login a user

with OpenID Connect it redirects the user's browser to the login page of the Connect2id server. The OpenID Connect request is encoded in the URL query string.

• The login page acts as the authorisation

endpoint in OpenID Connect / OAuth 2.0.

• The login page passes the URL query

string to the Connect2id server to decode and process the request. If required, the Connect2id server will prompt the login page for initiate user authentication or gather consent (explicit / implicit).

• Finally, the Connect2id server produces

the encoded authentication response, which the login page then relays back to the client app.

client app Connect2id server

HTTP 302 redirect HTTP 302 redirect login request login result encoded request, session cookie auth / consent prompt, encoded result

Login

User Password alice xxxx

Login page pseudo code

• 1. Pass the URL query string and browser cookie (if any) to the Connect2id server for

decoding and processing.

• 2. If the Connect2id server responds that the user must first be authenticated (due to no

session, or insufficient authentication):

• A. Authenticate the user with the indicated method, then:

a) On success: pass the user ID and the authentication details back to the Connect2id server b) On failure: stop

• 3. If the Connect2id server responds with a consent prompt:
• A. Present the consent form to the user
• B. Pass the obtained consent back to the Connect2id server
• 4. If the Connect2id server responds with a final response:
• A. Send the browser back to the client application

Example login page session (1)

POST /authz-sessions/rest/v2 HTTP/1.1 Authorization: Bearer ztucZS1ZyFKgh0tUEruUtiSTXhnexmd6 Content-Type: application/json { "query" : "response_type=code&client_id=s6Bhfa&state=xyz..." }

Pass the URL query string to the Connect2id server. If a session cookie is found it should also be included.

Example login page session (2)

HTTP/1.1 200 OK Content-Type: application/json { "type" : "auth", "sid" : "g6f5K6Kf6EY11zC00", "display" : "popup", "select_account" : false }

The Connect2id server response if the user needs to be authenticated

Example login page session (3)

PUT /authz-sessions/rest/v2/g6f5K6Kf6EY11zC00 HTTP/1.1 Authorization: Bearer ztucZS1ZyFKgh0tUEruUtiSTXhnexmd6 Content-Type: application/json { "sub" : "alice", "acr" : "https://acr.c2id.com/hisec", "amr" : [ "mfa", "pwd", "otp" ] }

Submit the user ID to the Connect2id server after successful authentication. The authentication strength (acr) and methods (amr) may also be indicated.

Example login page session (4)

HTTP/1.1 200 OK Content-Type: application/json { "type" : "consent", "sid" : "g6f5K6Kf6EY11zC00", "display" : "popup", "sub_session : { "sid" : "9yLXidrzk91r3BCpJeF1Vrf", "sub" : "alice", "auth_time" : 12345678, "acr" : "https://acr.c2id.com/hisec", "amr" : [ "mfa", "pwd", "otp" ], "data" : { "name" : "Alice Adams", "email" : "alice@wonderland.net" } }, "client" : { "client_id" : "8cc2043", "application_type" : "web", "name" : "My Web Store", "uri" : "http://my-web-store.com", "logo_uri" : "http://my-web-store.com/logo.jpg" }, "scope" : { "new" : [ "openid", "email" ], "consented" : [ ] }, "claims" : { "new" : { "essential" : [ "email", "email_verified" ], "voluntary" : [ ] }, "consented" : { "essential" : [ ], "voluntary" : [ ] } } }

The Connect2id server response if requested scopes / claims need to be

• authorised. The client and user session details are provided for context.

Example login page session (5)

PUT /authz-sessions/rest/v2/g6f5K6Kf6EY11zC00 HTTP/1.1 Authorization: Bearer ztucZS1ZyFKgh0tUEruUtiSTXhnexmd6 Content-Type: application/json

{ "scope" : [ "openid", "profile", "email" ], "claims" : [ "email", "email_verified" ], "access_token" : { "lifetime" : 600, "encrypt" : true }, "id_token" : { "lifetime" : 3600 }, "refresh_token : { "issue" : true } }

Submit the consented (explicitly or implicitly) scope and claims. Additional ones may also be freely included. The default token settings may be overridden, if required.

Example login page session (6)

HTTP/1.1 OK Content-Type: application/json { "type" : "response", "mode" : "query", "parameters" : { "uri" : "https://example.client.com/cb?code=5rZ_KxqZ &state=Nygv4CLQ" } }

Finally, the Connect2id server generates the redirect response for the client app

The session store endpoint

• Web API to enable query and management of the user sessions

stored in the Connect2id server

• The user session contains the user's ID and the authentication

details

• Arbitrary JSON data may also be stored
• Can be used by the login page to personalise / localise the UI
• Can be used by an admin or analytics tool / UI to view the users

who are currently online and what sessions they have

• Can be used to implement custom logout

Example user session

{ "sub" : "alice", "auth_time" : 12345678, "acr" : "c2id.acr.hisec", "amr" : [ "pwd", "otp" ] "creation_time" : 1234567, "max_life" : 20160, "auth_life" : 1440, "max_idle" : 15, "data" : { "name" : "Alice Adams", "email" : "alice@wonderland.net" } }

The direct authorisation endpoint

• Enables direct issue of ID /

access / refresh tokens for a client / user

• Implement token exchanges

(draft-ietf-oauth-token- exchange-05)

Example direct authorisation request

POST /direct-authz/rest/v2 HTTP/1.1 Authorization: Bearer ztucZS1ZyFKgh0tUEruUtiSTXhnexmd6 Content-Type: application/json { "sub_sid" : "g6f5K6Kf6EY11zC00", "client_id" : "8cc2043", "scope" : [ "openid", "email", "app:admin" ], "audience" : [ "http://app1.example.com" ], "claims" : [ "email", "email_verified" ], "claims_transport" : "USERINFO", "preset_claims" : { "id_token" : { "login_ip" : "185.7.248.1", "login_geo" : { "long" : "37.3956", "lat" : "-122.076" } }, "userinfo" : { "groups" : [ "admin", "audit" ] } }, "access_token" : { "lifetime" : 600, "type" : "IDENTIFIER" } }

Example direct authorisation response

HTTP/1.1 200 OK Content-Type: application/json { "id_token" : "eyJhbGciOiJSUzI1NiIsImtpZCI6IjFlOWdkazcif.ew...", "access_token" : "b15b843981cf", "token_type" : "Bearer", "expires_in" : 600, "refresh_token" : "YWxpY2U.NjU1NjRlYjAwNThk._W--XjP0UDZDiDYPkd4E_Q", "scope" : "openid profile app:admin", "sub_sid" : "g6f5K6Kf6EY11zC00" }

Authorisation store endpoint

• Web API to the store where long-lived authorisations are

persisted, keyed by subject and client ID

• Supports query, update and revocation of the authorisation
• bjects
• Optional call to inspect issued access tokens

{ "sub" : "alice", "cid" : "65564eb0058d", "scp" : [ "openid", "email", "app:write" ], "clm" : [ "email", "email_verified" ], "irt" : true, "atl" : 3600, "iss" : "http://server.example.com", "iat" : 1360050795, "dat" : { "abc" : "xyz" } }

The claims source SPI

• Enables plugin of one or more UserInfo claims sources.
• Standard Java Service Provider Interface (SPI).
• The SPI is published as open source package.
• The Connect2id server comes with a ready implementation for

retrieving UserInfo claims from an LDAP directory (also open- source).

• The SPI supports claims l10n.
• The SPI supports claim name advertising, to conserve

resources.

• The SPI can be decoupled via a web-service adaptor.

Claims source aggregation

Connect2id server

LDAP directory web service claims source SPI UserInfo request

access_token: eyJ9f...

SQL database Claims aggregation from multiple data sources

Backend databases

LDAP v3 MySQL 5.7.8+ PostgreSQL 9.5+ Redis 2.8+, 3.0+

Supported databases for persisting Connect2id server data (client regs, long-lived authorisations, etc)

Thank you!

Q A