Embed Size (px)
Citation preview
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 endpointsWeb-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 ☑profile ☒
denyAllow
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
Connect2idserver
HTTP 302redirect
HTTP 302redirect
loginrequest
loginresult
encoded request,session cookie
auth / consent prompt,encoded result
LoginUser Password
alice
xxxx
Login page pseudo code1. 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.1Authorization: Bearer ztucZS1ZyFKgh0tUEruUtiSTXhnexmd6Content-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 isfound it should also be included.
Example login page session (2)
HTTP/1.1 200 OKContent-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.1Authorization: Bearer ztucZS1ZyFKgh0tUEruUtiSTXhnexmd6Content-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 OKContent-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" : "[email protected]" } }, "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 beauthorised. The client and user session details are provided for context.
Example login page session (5)
PUT /authz-sessions/rest/v2/g6f5K6Kf6EY11zC00 HTTP/1.1Authorization: Bearer ztucZS1ZyFKgh0tUEruUtiSTXhnexmd6Content-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 OKContent-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" : "[email protected]" }}
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.1Authorization: Bearer ztucZS1ZyFKgh0tUEruUtiSTXhnexmd6Content-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 OKContent-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 objects
● 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
Connect2idserver
LDAPdirectory
webservice
claims sourceSPI
UserInfo requestaccess_token: eyJ9f...
SQLdatabase
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
