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 user authentication + shape explicit / implicit consent + plug-in any factor + ID / access token processing + choose factor based on context + custom token data + feed attributes into ID token IdP federation claims sources + SAML + plug-in any data source + social logins + DB and / or web service backends + legacy 3 rd party needs + aggregation from N sources 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? Use the available web APIs and Java SPIs Modifying the server code is never needed

Server endpoints + interfaces authz session direct authz session store authz store monitoring discovery JWK set Connect2id server client registration claims source SPI OpenID Connect provider token grant handler SPIs: + OAuth 2.0 server password ● client credentials ● token inspection + revocation SAML 2.0 bearer ● JWT bearer ● userinfo

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 3 rd 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 Consent Login Allow Wonderland App access to your : alice User ☑ email xxxx Password ☒ profjle Allow deny Design your own user experiences around login and consent

Sign-in UI, auth and authz When a client app wants to login a user ● HTTP 302 login client app with OpenID Connect it redirects the user's redirect result 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. Login The login page passes the URL query alice ● login HTTP 302 User string to the Connect2id server to decode request redirect Password xxxx and process the request. If required, the Connect2id server will prompt the login page for initiate user authentication or encoded request, auth / consent prompt, session cookie encoded result gather consent (explicit / implicit). Finally, the Connect2id server produces ● the encoded authentication response, Connect2id which the login page then relays back to server the client app.

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) Pass the URL query string to the Connect2id server. If a session cookie is found it should also be included. POST /authz-sessions/rest/v2 HTTP/1.1 Authorization: Bearer ztucZS1ZyFKgh0tUEruUtiSTXhnexmd6 Content-Type: application/json { "query" : "response_type=code&client_id=s6Bhfa&state=xyz..." }

Example login page session (2) The Connect2id server response if the user needs to be authenticated HTTP/1.1 200 OK Content-Type: application/json { "type" : "auth", "sid" : "g6f5K6Kf6EY11zC00", "display" : "popup", "select_account" : false }

Example login page session (3) Submit the user ID to the Connect2id server after successful authentication. The authentication strength (acr) and methods (amr) may also be indicated. 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" ] }

Example login page session (4) The Connect2id server response if requested scopes / claims need to be authorised. The client and user session details are provided for context. 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" : [ ] } } }

Example login page session (5) 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. 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 } }

Example login page session (6) Finally, the Connect2id server generates the redirect response for the client app HTTP/1.1 OK Content-Type: application/json { "type" : "response", "mode" : "query", "parameters" : { "uri" : "https://example.client.com/cb?code=5rZ_KxqZ &state=Nygv4CLQ" } }

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 ●