Download presentation
Presentation is loading. Please wait.
1
Security for Science Gateways Initial Design Discussions
Custos Security for Science Gateways Initial Design Discussions
2
High-Level Overview
3
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
4
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)
5
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)
6
Use case 1: Institutional Login
GW Custos IDP OIDC Custos AuthN Redirect SAML CILogon AuthN Redirect AuthN SAML AuthN Login
7
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)
8
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
9
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
10
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
11
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
12
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
13
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
14
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
15
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.
16
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
Similar presentations
