210 likes | 266 Views
OpenID Connect ( OIDC ) Recap. Authentication protocol on top of OAuth2 Three different tokens: Access Token (AT): for authorization with a service / resource (OAuth2 and OIDC) Refresh Token (RT): to obtain additional access tokens (OAuth2 and OIDC)
E N D
OpenID Connect (OIDC) Recap • Authentication protocol on top of OAuth2 • Three different tokens: • Access Token (AT): for authorization with a service / resource (OAuth2 and OIDC) • Refresh Token (RT): to obtain additional access tokens (OAuth2 and OIDC) • ID Token: contains user information (only OIDC) • Several flows: • Authorisation code flow (standard web flow, e.g. “Sign in with Google”) • Implicit flow (mainly for SPAs) • Refresh flow (to obtain additional ATs from a RT) • Device flow (for input constrained devices (e.g. TVs) • Dynamic client registration flow • ... 7 Acronyms only on this page...
The problem • Currently, OIDC works well.... in the web • Some use cases require using non-web-OIDC • Applications that use REST and federated identification • Data management (webDav/OIDC, remote job/container/vm submission) • Delegated authentication (Server acts on my behalf, e.g. get data from yet another server) • Development, interactive use on the commandline • Obstacles when using non-web-OIDC • Obtaining the Access Tokens (ATs) is not yet facilitated by tools • Cumbersome and (sometimes) long strings • Lifetime (~10min) requires frequent renewal • Current solution: • Copy-paste from web applications
Requirements for a solution • Provide an easy to use interface so that • Applications can easily obtain access tokens (ATs) • Users can obtain ATs on the command line • syntax that allows easy integration into other program calls • Integration with major linux distributions • Provide access tokens (ATs) to • applications • interfaces for Applications that need ATs • commandline • Hide complexity: • refresh token, ID token, client registration, client secret handling, how many users per client? • Handle / hide OIDC specific communication • Security • Strong cryptography, careful implementation, security audits
Our solution oidc-agent • Design based on ssh-agent: • ssh-agent => oidc-agent: Daemon, usedto • CommunicatewithOpenID Provider • Interface toclients • Store secrets in (encrypted) memory • ssh-keygen => oidc-gen: • Register OIDC clientand initialise configuration • Store encrypteddata (RefreshToken, client_secret, ...) • ssh-add => oidc-add: • Prompt forpassword and loadsecretsintoagent • ssh => oidc-token: • Obtain and return an accesstoken
oidc-agent - Advanced features • Agent isintegratedwithXsessiontoautostart at startup • Agent canmakeuseofssh-askpasstoloadconfigurations, whennecessary • Agent forwarding: • sshto remote hosts • private material (i.e. refreshtoken) neverleavesthelocalmachine • Support for debian-, redhat- and mac-os basedsystems • Works withmanyOIDC providers: • IAM, EGI-Checkin, eduTeams/satosa, Shibboleth, Human-Brain, B2Access, ... • Supports multiple profiles (useraccounts in different OIDC providers)
oidc-agent - Client registration • Client registration is rather complex, and depends on OIDC Provider • Many options for client registration: • Dynamic client registration (default) • oidc-agent self-registers himself as a new client • depending on the provider, this may require an initial token • not supported by all providers • IAM, HBP (protected) • Public client (fallback) • oidc-agent comes as a public client for all providers that support it • pre-registered by us with the correct configuration parameters and approved by the provider • not supported by all providers • KIT, Google, IAM, HBP, Elixir, EGI • Manual client registration (fallback of fallback) • user registers a client manually (e.g. through a web interface) • user has to specify the correct configuration parameters • eduTEAMS, HDF, B2Access
oidc-agent - Security highlights • All sensitive information on diskisencrypted (usinglibsodium) • Everything(senstive) in RAM isobfuscated (dynamicrandompasswords) • Privilege separationsupported • Enforcement via seccompavailable(off by default) • Separate processesfordisk- and network access • Keep theuserfrom stupid moves • unlikesshwe do allowthem (ifyou RTFM)
oidc-agent - usage • Generating a new account configuration: • General: $ oidc-gen [<shortname>] • IAM • $ oidc-gen iam • EGI-Checkin • $ oidc-gen --pub egi • Google • $ oidc-gen --pub google • Any other provider: • https://indigo-dc.gitbooks.io/oidc-agent/provider.html#how-to-get-an-account-configuration-with
oidc-agent - usage • Obtaining access tokens from the agent: • $ oidc-token <shortname> • Prints the AT for the requested account configuration • $ curl -H “Authorization: Bearer `oidc-token <shortname>`” https://…. • Integrate the oidc-token call into another command, e.g. curl call • $ export OIDC_AT=`oidc-token <shortname>` • Put the AT into an environment variable • $ eval `oidc-token -oOIDC_AT–c <shortname>` • Put the AT into the OIDC_AT environment variable • There is also additional information available (expiration time, issuer url, ...)
oidc-agent - usage • Applications that need an AT can obtain an AT directly from the agent: • User does not have to pass anything (in some cases the shortname) • Applications can assume valid ATs • While content of environment variable would expire at some point • API interfaces available for c, go, and python • Applications that use oidc-agent: • wattson • orchent • feudalSSH • unicore command line client
oidc-agent - Compatibility • oidc-agent was tested to work with the following providers: • Eudat / B2Access • eduTEAMS • EGI-Checkin • Elixir • Google • Helmholtz Data Federation • Human Brain Project • IAM (Indigo, Deep, Extreme) • KIT • It’s easy to get oidc-agent to work with any OpenID Provider. In case of problems, please contact us: oidc-agent-contact@lists.kit.edu
oidc-agent - Summary • https://github.com/indigo-dc/oidc-agent • *Star* the project, if you like it! • MIT License • Documentation: https://indigo-dc.gitbooks.io/oidc-agent/ • Available for: • Debian/Ubuntu: http://repo.data.kit.edu/ • CentOS7: https://github.com/indigo-dc/oidc-agent/releases • MacOS: https://indigo-dc.gitbooks.io/oidc-agent/macos.html#installation • Windows: Might come, if there is interest. Let us know. • Subscribe to updates: https://www.lists.kit.edu/sympa/subscribe/oidc-agent-user
For the Tutorial • Get an account in iam-demo: https://iam-demo.cloud.cnaf.infn.it<= http_S_ • Install oidc-agent: • debian/ubuntu: Find instructions at http://repo.data.kit.edu<= just http ;) • All others (redhat/scili/.../mac) • See the README at https://github.com/indigo-dc/oidc-agent • Check if agent is available: • oidc-token iam • If there’s an error: start the agent: • eval `oidc-agent | tee /tmp/oidc-agent.env` <= Backticks • Link* your oidc-agent with the account in IAM • oidc-gen --pub iam • ...follow the instructions • Test it: • oidc-token iam <= This gives you an AccessToken • *Link: • register the oidc-agent as a client with IAM • using a public client • Perform an auth code flow • Obtain a refresh token and store it
oidc-agent - security features • Privilege separation • Custom memory (un-)allocator - all memory is cleared before free • User credentials are not stored to disk • No user information is processed • All stored data is encrypted • No private data leaves the user’s machine • Only outgoing connection to OpenID Providers (no inbound conn. required) • Sensitive communication between the different components is encrypted • Socket access rights managed by the file system • Sensitive data in memory is obfuscated with a dynamically generated secret • When the agent is locked, additional encryption is applied to all sensitive data • Process not traceable by non-root users • Optional seccomp support • PKCE
oidc-agent - technical view - OIDC clients • oidc-agent uses an OIDC client for every account configuration • Multiple account configurations for the same provider can share same client • Many options for client registration: • Dynamic client registration • default option • registers a new client, for every account configuration • each user has its own client(s) • depending on the provider, it might require an initial token • not support by all providers • Pre-registered public client • fallback, if dynamic client registration not supported / fails • pre-registered by us with the correct configuration parameters and approved by the provider • shared by multiple users • not supported by all providers • Manual client registration • user registers a client manually through a web interface • each user has its own client(s) • user has to choose the correct configuration parameters
oidc-agent - technical view - general principle • On account configuration generation: oidc-agent obtains a RT • Afterwards: Obtaining ATs by using the RT in the refresh flow • RT has to be obtained only once, then only refresh flow • Obtaining the initial refresh token: • (Out of band: Provided by the user) • (Password flow) • Authorization code flow • Device flow +--------+ +---------------+ | |--(A)----------- Refresh Token ----------->| Authorization | | Client | | Server | | |<-(B)----------- Access Token -------------| | +--------+ (w/ Optional Refresh Token) +---------------+