Tuesday, 2022/05/24
10:00 am ET
Terrell Russell, Alan King, Kory Draughn, Dave Fellinger, Stefan Wolfsheimer (SURF), Claudio Cacciari (SURF), Tony Edgin (CyVerse), Harry Kodden (SURF), Alexandros Kardaris (SURF), Mike Conway (NIEHS)
DISCUSSION
- Alan Update
- 4.3.0 is imminent (just have to package and publish)
- Renamed the plugin to pam_password
- So now...
- pam - shipping with server - still the 4.2 plugin
- pam_password - shipping with server - ported to new 4.3 framework
- pam_interactive - from stefan's work, not shipped with server
- osauth - will not being ported
- krb - ported, mostly, passed tests - not shipping with server
- Stefan Update and Demo of pam_interactive
- Goal was flexible flow, not just single password challenge
- iinit working
- Demonstrated simple.py, 2fa.py, and 2fa_expire.py
- But hit uncaught exception for ils, but probably due to not using native for the 'already authenticated' client
- Alan links
- Here is the server-side auth operation which generates the temporary password and gives it back to the plugin
- And then the saved result is saved to the .irodsA file on the client side in the plugin here:
- Here's the operative piece of authenticating with iRODS, as far as I can tell. Just setting the auth level of the client in the RsComm in the agent. The plugin can reach this "conclusion" in any way that it pleases (including just letting everybody do everything)
- Stefan Links:
- Code interactive pam branched from irods master
- Pam-python module
- developed with slow pace
- not sure if can be used in production, good for prototyping
- https://github.com/Ralnoc/pam-python
- Pam stack examples using the pam-python module
- Should we remove the irods-server's knowledge/opinion of pam password lifetime?
- Surf use case, want to refresh a token from OIDC server
- Should be possible with pam_interactive storing/refreshing tokens in the background
- Surf use case, want to refresh a token from OIDC server
- Plugin framework should perhaps define a 'hangup' or 'end' that iexit calls, so plugins could store information on the server side, and then remove it upon request. Every plugin would need to implement this 'end' function.
- If information should be stored per user, then it could be sqlite file? But that is still per server.
- Or perhaps the client-side function would call 'end'... does that break inter-version compatibility in the future? What if 'end' isn't required… just runs if defined?
- Prepare talk for UGM 2022
- Next Meeting
- June 2022