20230124-minutes.md

Authentication Working Group Minutes

Tuesday, 2023/01/24

10:00 am ET

Attendees:

Terrell Russell, Alan King, Kory Draughn, Dave Fellinger, Claudio Cacciari (SURF), Harry Kodden (SURF), Mike Conway (NIEHS), Martin Golasowski (IT4I), Mohamad Hayek (LRZ)

Minutes

SUMMARY:

DISCUSSION

• RENCI update
  • iinit - PR almost merged - will be in 4.3.1
  • C++ REST API needing PAM/OIDC
    • Not clear how to do this / tie it in with this WG conversation
    • pam_interactive 'assumes' a TTY is on the other end?
      • This is insufficient for a passthrough scenario like REST API
    • iinit (client) just calls client side plugin directly and assumes it returns a YES/NO
    • For REST API, REST API is the client… and needs to go back to the human for inputs… and it's not currently part of the flow
    • Client -> REST API -> iRODS
    • Access token 'as' bearer token on the REST->iRODS stage?
  • Success could be shown with REST API doing its own OIDC/OAuth dance
    • REST API could be 'fixed' 2FA (or whatever we decide)
    • Then passing authenticated token to iRODS, which would use the same system on the backend to 'know' this is legitimate
    • iRODS would then know 'who' was authenticated
  • Break up the problem
    • Browser to OAuth/OIDC/SAML, then
    • rodsadmin proxying the mapped/tokened user to iRODS
  • SURF - Focus on the protocols directly
    • The use particular implementations (keycloak) as confirmation
• LRZ - Converting iinit to 4.3.0
  • Adding pam_password awareness to iinit: https://github.com/irods/irods_client_icommands/commit/77873e0568074b572c12e7df563142843aa22feb
  • Porting authentication plugins to new framework
    • Plugin framework/native: https://github.com/irods/irods/commit/35e3c9ee9d6112a8f1f3f5ce118997f2d6bb3259
    • pam_password: https://github.com/irods/irods/commit/419734e7f2f4ea8c851096460dce7f37908113f2
    • Kerberos (unreleased): https://github.com/irods/irods_auth_plugin_kerberos/pull/54/commits/231c01401f8d73add3fe50bbd256a09e45fd300c
• What if iRODS allowed mapping of arbitrary incoming tokens to known iRODS local accounts?
  • Would be generic to any kind of auth
  • Could get the mapping from an external source
    • Rather than keeping a local sync from AD/etc.
  • Could map multiple incoming accounts to map to single iRODS user
  • Could map single incoming account with attribute to different iRODS users
• Could be one single pam_interactive plugin that knows multiple protocols/tokens
  • Single source of truth
• Or multiple smaller pam_specific plugins, used in a cascade
  • Smaller maintenance profile/pressure
• Mike/NIEHS - using keycloak to authenticate first, then use that token to talk to Jargon
  • Working on a keycloak plugin, to talk with the DRS REST API
• Next Meeting
  • Feb 2023