20200428-minutes.md

Authentication Working Group Minutes

Tuesday, 2020/04/28

10:00 am ET

Attendees:

Terrell Russell, Jason Coposky, Kory Draughn, Alan King, Jaspreet Gill, Ton Smeele (Utrecht), Mike Conway (NIEHS), Tony Edgin (CyVerse), Brett Hartley (Sanger), Claudio Cacciari (SURFsara), Sarah Roberts (CyVerse)

Minutes

SUMMARY:

Use Cases:

• 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

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
• Many-to-many mapping external IDs to internal iRODS usernames
• Automatic provisioning
• PAM can provide attributes, and iRODS rule/policy can handle the mapping based on that attribute

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.

PROPOSAL:

• Consortium will provide:
  • API plugin that speaks JSON and talks to Gen2 auth plugins
  • JSON schema to define this messaging
• Clients drive the conversation... Given that all plugins are completely open ended we can have as many JSON-driven operations as we need, called in any order by the client. The server manages the conversation.
• Successful authentication is simply a flag from the server.
• API can track which kind of auth a user has used, auth scheme is already stored in the user info struct. Can provide error messages to client, if appropriate.

DISCUSSION:

New repository - with the API plugin ... auth plugins could also be in that same repo, or separated out once more mature...

PAM plugin would be a new Gen2 auth plugin - the client calls the new API endpoint, which converses with the PAM plugin as per the arrangement in the JSON...

QUESTION: "How about externally defined entitlements? How will these be passed around? E.g. if I am in group ‘student’ in shibboleth, how can auth groups in iRODS intersect?
"

• Could easily add keyval to a couple interactions for conditional inputs

Give all auth flow responsibility to the plugin

Each plugin would provide both client and server side flow...

• Native
• PAM
• OpenID
• OAuth2
• CAS
• Kerberos
• KeyCloak
• SAML

Could also have server-side policy to control Authorization based on how someone came in the front door... could be based on rsComm user information... the servers already know how someone got in. Any attributes coming from Shib or PAM... could be part of the conditional inputs into the user information.

QUESTION: external openid... converted to an iRODS id... any mappings should be on the server side, agreed.

QUESTION: how does the user get a token.... An implementation detail of any particular plugin. If the plugin gives back a token to the user... they would cache it and use it again... the plugin would handle/recognize that token and proceed as authed...

QUESTION: how does a plugin demand encryption... ? same as today... on a client connection.

New repo at...

• irods/irods_api_plugin_authentication
• irods/irods_api_plugin_flexible_authentication
• irods/irods_api_plugin_client_driven_authentication Or... just work in the working group repository for now until we learn more of the shape of this

QUESTION: "How do you handle ‘any’ versus ‘all’ type ops 
e.g. native OR OIDC" if the server has multiple auth mechanisms in place... how does the client choose? What if the server has a strong opinion otherwise? What about fallthrough on failure?

ACTION ITEM: Consortium implement

• first draft of this Gen2 API...
• a development package for clients/plugins to be built against
• first example plugin with the native authentication flow from today (PAM #2 in line).
• diagram of connection/flow