Managing OIDC Clients and Use Cases in Federated Environments
Explore the diverse use cases and architectural details of managing OIDC clients within federated environments, including WaTTS OIDC-Agent and OIDC-Gen solutions. Learn about enabling legacy services with federated identities and the challenges and considerations in dynamic client registration with OIDC providers.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
Two OIDC clients To provide use-cases for OIDC/fed Marcus Hardt KIT University of the State of Baden-W rttemberg and National Laboratory of the Helmholtz Association www.kit.edu
Two Use Cases WaTTS OIDC-Agent 2 OIDC clients
WaTTS Enable legacy services to leverage federated identities Legacy services: X.509: Provide certificates that were issued by with RCauth.CA SSH: Simple key upload/provisioning serviceS3, OpenNebula, MYSQL: Local account creation (requires manual work by local admin) Extensible via plugins Written in Erlang OIDC library: OIDCC (https://github.com/indigo-dc/oidcc) Currently running 4 instances https://watts.lifescienceid.org, https://watts.pilot.lifescienceid.org, https://watts.data.kit.edu, https://watts-dev.data.kit.edu 3 OIDC clients
Usecasewise Standard OIDC client Standard web flow There s also a REST interface Roughly 30 installations expected 4 OIDC clients
OIDC-Agent: Motivation: CMDline + API access require non-web authentication Guiding Pattern: ssh-agent oidc-agent (net) Daemon that handles OIDC tokens and communication Tool to register the client with an OIDC provider Use several flows and dynamic client registration to register the client oidc-gen (disk-rw) User frontend for initiating new account creation Store encrypted OIDC data (RefreshToken, ClientID, ClientSecret) oidc-add (disk-r) Tool to decrypt / load / remove OIDC data and pass to agent oidc-token Tool to obtain AccessToken Deployment Scenario: One or more clients per user => Automatic registration is important 5 5 OIDC clients
OIDC-Agent Architecture 6 6 OIDC clients
OIDC-Gen Register with the OIDC-P Dynamic recistration currently difficult Supported flows (to obtain refresh token): Password flow => OPs don t like to release refresh-token Code flow => Requires a local webserver (working on it) Device Code flow => Future work Supported OPs Indigo-IAM: password flow is not included in dynamic registration (required admin) B2Access: Dynamic-registration is not supported EGI-Checkin: Missing offline access-scope (i.e. no refresh token) => No oidc-agent HBP: Still discussing dynamic-registration; Still under development => We probably implement anything to simplify dynamic registration . 7 OIDC clients
Quick usage Once in a lifetime: oidc-gen <name> For now: ask OIDC-P admin to enable refresh tokens for the password flow oidc-gen f <file> <name> Use password flow to get RefreshToken After reboot: eval `oidc-agent` Each time you need a new token: oidc-token <name> DEMO :wq 8 8 OIDC clients
Security features Privilege separation: oidc-add and oidc-gen Only access to local disk and oidc-agent (via IPC), no network required oidc-agent The only component with network access, disk access only required for ca- bundle oidc-token Only IPC communication Decrypted credentials only in RAM All disk-stored credential are crypted using libsodium Use own free() method to wipe memory when deallocating 9 9 OIDC clients
Current work Password grant type and dynamic registration are incompatible for security reasons Right now this requires the user to communicate with OIDC-P admin after registration Will be fixed by implementation of a local webserver (oauth2 code flow) Then also google will work (they don t support password flow at all) IAM about to support the device-code-flow (draft RFC) Implement privilege separation 10 10 OIDC clients
Links https://github.com/watts-kit https://github.com/indigo-dc/oidcc https://github.com/indigo-dc/oidc-agent https://indigo-dc.gitbooks.io/oidc-agent 11 11 OIDC clients
