Tuesday, 2020/10/27
10:00 am ET
Terrell Russell, Jason Coposky, Kory Draughn, Alan King, Markus Kitsinger, Bo Zhou, Ton Smeele (Utrecht University), Mike Conway (NIEHS)
DISCUSSION
-
Considerations around reconnection. PAM gets temporary password. KRB and GSI does not… will need to go back and check how it's reconnecting/reauthenticating.
-
UU considering OIDC, and how does the reauthentication/reconnection work?
-
Violent agreement that using tokens only… JWTs… or perhaps keycloak… is the future
-
OIDC via PAM (on the backend) is the current way for UU… would like to move to OIDC in the frontend
-
iRODS server would need to be the piece that authenticates to the OIDC system, or every client needs to learn how to speak OIDC… which is not unreasonable
- Would mean there's an OIDC auth plugin for iRODS, iRODS server is a relying party (RP)
-
Reinvented OIDC...
- https://darutk.medium.com/diagrams-of-all-the-openid-connect-flows-6968e3990660
- 0 - iRODS Server must register within the IDP - 'application' within the IDP - gets an application ID and a shared secret token
- 1 - client gets authorization code - IDP certifies this user X grants access to its attributes to server iRODS
- 2 - client sends authorization code to iRODS server, iRODS confirms with IDP, and user is authenticated - iRODS server provides an access token (with a limited time) for reuse by the client without reauthenticating
- 3 - client uses access token to request operation (api call) to iRODS server - if expired, then go back to step 2 to get new access token
- client can request authorization code be revoked?
- everything can be curl calls
- limit use case for now to icommands/iinit
- select possible IDPs, iRODS provides IDP URL, iRODS server awaits good token from client (from step 2)
- step 3, icommand makes iRODS server API call with good access token
- federated IDPs are a little more complicated, but adds perhaps another redirect for the user, but could be made seamless
- does keycloak already do all this... to be investigated
-
Report from SURF - all functionality moved into their new plugin - only thing required is a tweak to iinit to start the flow (which would be in a new release of iRODS, presumably). We need to decide how to handle this… a new endpoint, alongside old… with preference for first and fallthrough to old… or same endpoint with naming conventions to determine flow. Second option has fewer moving parts, but creates a namespace within the plugin names (not ideal).