Security for Science Gateways Initial Design Discussions Custos Security for Science Gateways Initial Design Discussions

High-Level Overview

Use case 1: Institutional Login GW Custos CILogon IDP OIDC Custos AuthN Redirect OIDC CILogon AuthN Redirect SAML CILogon AuthN Redirect AuthN AuthN Login SAML AuthN

Use case 1: Institutional Login Kind of doing repetitive work. Validate SAML Token GW Custos CILogon IDP OIDC Response (Redirect) OIDC Response (Redirect) OIDC Response SAML Authn Response OIDC Response SAML Authn Response (Redirect)

Use case 1: Institutional Login Unify. Validate SAML Token GW Custos CILogon IDP OIDC Response (Redirect) OIDC Response (Redirect) OIDC Response SAML Authn Response OIDC Response SAML Authn Response (Redirect)

Use case 1: Institutional Login GW Custos IDP OIDC Custos AuthN Redirect SAML CILogon AuthN Redirect AuthN SAML AuthN Login

Use case 1: Institutional Login Validate SAML Token Keycloak can validate the token. GW Custos IDP OIDC Response (Redirect) SAML Authn Response OIDC Response SAML Authn Response (Redirect)

Resource Authentication Good for having something working Thinking backward This is what I did for a while That is understand the functionalities cloud providers giving for delegated/federated authentication and try to implement our use case. Thinking forward Implement the custos use case and list what we need from cloud providers. Good if we can influence cloud provides

Users Types of users as far as resources are concerned Forward Types of users as far as resources are concerned Users with proper authentication credentials to the resource (resource user) Users without proper authentication credentials but authorize to use credentials of a user who has credentials to a resource.(none resource user) Types of users as far as resource is concerned (AWS): Root User (has a dedicated AWS billing account) IAM User (associated to another root account) Neither root nor IAM (no relationship to AWS at all) Backward

Use Case 2: Adding a resource by a resource user GW Custos Resource (AWS/GCP) Custos AddResource Redirect Oauth Resource Redirect AddResource Authorize Add Resource Oauth Scopes are defined based on what user specified. Specify what retrieving credentials can do. E.g., execute code, access s3

Use Case 2: Adding a resource by a resource user Store Auth code GW Custos Resource (AWS/GCP) Success Redirect Auth Code Auth code, redirect to Custos Resource Added

Use Case 3: Accessing a resource by a resource user Is access token along sufficient? Get Credentials GW Custos Credentials Access Token Auth Code SDK+ Credentials (Access token) Resource (AWS/GCP) Access Resource

Use Case 4: Accessing a resource by a none resource user In order for none resource user to access a resource, he/she must be associated with a resource user. Associate auth codes with different entities: Single user (resource user) A group A role

Use Case 4: Accessing a resource by a none resource user Find associated auth code(s) Get Credentials GW Custos Credentials Access Token Auth Code SDK+ Credentials (Access token) Resource (AWS/GCP) Access Resource

Use Case 4: Accessing a resource by a none resource user Every user in the group has same access privileges. We lose audit logs at the resource but we can maintain audit logs at the custos. If we want functionalities similar to throttling we need to implement them at the custos level.

Custos Components Single server that embeds KeyCloak and other functionalities API KeyCloak User Management CredentialStore/Vault Primary user store Storing auth codes, ssh keys, generate keys Sharing Service Manages resource authentication for a user + throttling, limiting user access to resource. Profile Service Resource Authentication/ Authorization Admin/ Monitoring Registering client ids, client secrets + other admin/monitoring things Secure audits, manages audit queries Auditing