Skip to content

Latest commit

 

History

History
57 lines (49 loc) · 3.61 KB

20240123-minutes.md

File metadata and controls

57 lines (49 loc) · 3.61 KB
Raw

Authentication Working Group Minutes

Tuesday, 2024/01/23

10:00 am ET

Attendees:

Terrell Russell, Kory Draughn, Alan King, Martin Flores, Claudio Cacciari (SURF), Harry Kodden (SURF)

Minutes

SUMMARY:

DISCUSSION

  • OIDC/OAuth2 in HTTP API
    • Initial release 0.1.0, Nov 7 2023
    • 0.2.0 coming very soon (2 open issues)
      • Support for OIDC via HTTPS
      • Simplified OIDC configuration, now single key/value
      • Configuration validation via JSON Schema
      • Admins can choose which property in the OIDC JSON response represents the iRODS username claim
        • This is 'normal' to be used as a trusted value, use it directly to iRODS
        • Additional / more complicated mappings are possible, but not necessary in the near term for initial use cases
    • Investigating changing the role of the HTTP API in the Authorization Code Grant flow
      • irods/irods_client_http_api#155
      • Possibly iinit becomes the OIDC client (learn how to do all the things)
        • Configuration still in the API (actively shared with the client)
      • Then the API is just the OIDC resource server (fewer moving parts)
        • Could just do validation locally via public key from OIDC server
  • pam_password in 4.3
    • History: Introduced to provide pseudo backward compatibility for legacy PAM plugin users as we transitioned to using the client-driven authentication framework (from working group) for 4.3.0. Named to express capabilities/limitations of the plugin and keep the “pam” plugin name open for the future.
    • Eventually, we would like to phase this out in favor of The One True PAM Plugin, which could actually implement this behavior itself (Maybe! See below…). It will need to be supported into the future at least in 4.3.x for backward compatibility.
    • How can a generic PAM auth plugin implement the historical limited-lifetime passwords in the iRODS catalog? Are we going to continue to support that paradigm? Remember: This was introduced to reduce the amount of traffic hitting the PAM service…
  • pam_interactive?
    • We need to test this plugin before it can be released. How do we do that?
      • The existing examples use pam_python and this is known to be unsuitable for production environments.
      • Do we need to write our own PAM module(s) for testing various interactive flows and configurations?
    • How does this interact with clients that are not iinit? Other iCommands? Python iRODS Client library? Go? HTTP? Aka non-command line clients.
      • No testing yet. Most interested in python client first. But solving it with PRC should be sufficient for other languages. Perhaps PRC 'pretends' to be a terminal and that is sufficient as well… not sure yet.
    • How will this interact with “the future of authentication” in iRODS? Specifically thinking about the HTTP API here…
      • Is this a 4.3.x-only effort? Is it possible to release this for already-released 4.3.1 without a change in the server?
  • Discussion - with pam_interactive
    • custom pam module would serve as traffic cop / truth
      • if good 'session' already active…
        • just return, no checking with PAM stack
      • else, check with PAM stack first, get response back (perhaps along with TTL)
        • set temporary password (honoring any TTL returned by pam stack)
    • Minimum viable plugin -> pam_python
      • Then translate to simple C-based module
      • Possible example from Harry - generic device code flow on gitlab
    • Next steps - early beta / working
      • Harry to receive a build of pam_interactive to setup a testing stack
      • Will target Ubuntu22, 4.3.1
  • Next Meeting
    • Feb 2024