Tuesday, 2020/03/24
10:00 am ET
Terrell Russell, Jason Coposky, Kory Draughn, Alan King, Justin James, Dave Fellinger, Jaspreet Gill, Sietse Snel (Utrecht University), Deep Patel (NIEHS), Tony Edgin (CyVerse), Edwin Skidmore (CyVerse), Brett Hartley (Sanger), Lazlo Westerhof (Utrecht University), Claudio Cacciari (SURFsara), Nirav Merchant (CyVerse), Ton Smeele (Utrecht), John Constable (Sanger), Stefan Wolfsheimer (SURFsara), Sarah Roberts (CyVerse),
Status:
- iRODS Consortium suggestion of an API plugin
- would provide new api endpoint for new clients, alongside old/current API endpoint for current clients
- would consolidate SURF PAM standalone handshake service into iRODS server
- iRODS Consortium will facilitate an Authentication Working Group
- define the problem and the proposal in public
- work with multiple community members
- produce working code
Discussion:
What do the flows need to support? Target implementations?
- SURF / Utrecht - PAM, OpenID, SAML, two factor
- CyVerse - cli, moving from CAS to keycloak (limited by length) https://www.keycloak.org uses OAuth2, openid, two factor, AWS/S3-style keypair, tickets (distributed computing), ORCID becoming requirement for funding agencies Oct 1 2020 (allowing users to move between institutions over time and keep their same access)
- Sanger - https://www.okta.com/products/customer-identity/authentication/
- NIEHS - existing anonymous/ticket/tokens (GA4GH use cases), https://www.ga4gh.org/work_stream/data-use-researcher-identities-duri-2/
- Utrecht - avoid sending passwords over the line, distinguish between social accounts and 'real/institutional' accounts, prioritization -> mapping, how do we 'reduce' auth over time / deprovision
This means... iRODS Catalog would not necessarily be the source of truth for auth.
Have to externalize the trust to (an)other system(s).
Possibly interested in certification for the iRODS server... against certain technologies/standards.
- HIPAA - environment itself is blessed as a stack
- ITAR
- FISMA
iRODS server just becomes a relying party (RP)? Trusts a list of identity providers (IDP).
- Having conversation with the client
- Handling the state in the backend/server
Mapping external IDs to internal iRODS usernames - automatic provisioning? Or many-to-many user/id mappings. PAM can provide attributes, and iRODS rule/policy can handle the mapping based on that attribute.
Existing PAM module handles a single external IDP, today - then second stage going directly to IDP, using that ID as truth.
Lessons from ... Shibboleth -> entitlements -> iRODS groups (Kings College)
What technologies/stacks/solutions can we copy/emulate?
- Google SDK and utilities (CLI to browser and back)
- Google PAM cache
- Openfaas - https://docs.openfaas.com/reference/authentication/ (another example of cli using oauth2)
CONSIDERATION: should this be zonewide? Some might want Kerberos for personal use, but something else for HPC… pipelines doesn't need to be reauthenticated every time / as often. Another vote for keeping tickets/tokens as first class citizens in this new scheme.
CONSIDERATION: Ability to tie in # of uses (like tickets has) to particular users / auth , and some mechanism for re-upping/allocating new uses over time.