Hi Vahid, Thanks for the followup info.
> assume a role defined by a user for that user's access only I think in Custos we want the ability for users to share resources (e.g., a dataset in S3) with members of a collaboration group, where group sharing policies are defined in Custos. For example, we might put an isMemberOf claim in the id_token and set AWS S3 policies on that. Since a SciToken is also a JWT, I wonder if we could set an AWS policy to accept a SciToken for capability-based access. > unlike user authentication that can be asserted by standard protocols > (e.g., OIDC, OAuth2.0, and etc.), authorization or access delegation to > cloud-based resources is via vendor-specific protocols and methods True for some cloud-based resources (AWS and Azure). Others like Google Drive and Box and DropBox support OAuth. Globus has nice documentation for the Google Drive delegation process: https://docs.globus.org/how-to/access-google-drive/ > Galaxy must have received an identity token issued by CILogon for > the given audience ID (e.g., not the identity token keycloak generated > after it has received CILogon authentication confirmation). In the case of a campus->cilogon->keycloak->galaxy authentication, I expect Galaxy to obtain an id_token from keycloak that includes the user's "Custos" identity (e.g., with Custos group memberships), so we'd configure the AWS policy to accept the keycloak id_token for authorization. > Also, CILogon/Custos/Keycloak should be able to validate the identity token > Galaxy has presented AWS (see steps 15 and 16 on Figure 4 in our manuscript > https://doi.org/10.1101/506238). I was confused by those steps in the paper. Doesn't AWS simply verify the id_token directly following the steps in https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation? A callback to the ID Provider shouldn't be required to verify the id_token. I expect we just set up the ID Provider following the instructions at https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html so AWS can verify the digital signature on the id_token, but I need to test it... > If you have implemented means of getting id tokens from > CILogon/Custos/Keycloak, you should be able to use CloudAuthz directly. Reading https://github.com/galaxyproject/cloudauthz/blob/dev/cloudauthz/providers/aws.py I see that https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html is the call I need to make to exchange the id_token for credentials. I'll try that... Regards, Jim ________________________________________ From: Vahid Jalili <[email protected]> Sent: Friday, February 22, 2019 5:10 PM To: [email protected] Subject: Re: Custos Galaxy AWS CloudAuthz Hi Jim, That is an interesting point. Some aspects to consider: - this model assumes that a user trusts Galaxy for: a- assume a role defined by a user for that user's access only (not assume it for any user on that Galaxy instance); b- use the temporary credentials obtained as a result of assuming a role, to sign the requests of a Galaxy user who defined the role; - unlike user authentication that can be asserted by standard protocols (e.g., OIDC, OAuth2.0, and etc.), authorization or access delegation to cloud-based resources is via vendor-specific protocols and methods; some offer fine-grained measures of mutually satisfying principals of each others authNZ, and some merely implement plain text secrets. This emphasize the relevance of the previous point, since Galaxy has a multi-cloud approach. - regarding the AWS trust relationship you mentioned: you can either define a `sub` as you mentioned, or use a field called ExternalID <https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html> and set its value to Galaxy user ID or your Gmail address, and ask Galaxy to populate that filed appropriately while assuming the role. Two points worth mentioning: a- I had lots of challenges using this field in past, so decided to remove it from the manuscript until the implementation is solid; b- even with such fields, the user still needs to have some trust in Galaxy (first point) for not using their Galaxy user ID to compose role assumption requests for another Galaxy user. To configure the role to accept CILogon/Custos/Keycloak id_tokens, > https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-idp_oidc.html > makes > me think we just replace "accounts.google.com:aud" with "cilogon.org:aud" > or "iamdev.scigap.org:aud" following the "server.example.com:aud" > pattern. Anyone want to help me test that scenario? The IdP key and value in `StringEquals` should match the ID token Galaxy will present AWS STS. In other words, if we set that filed to "cilogon.org:aud" : "abc", Galaxy must have received an identity token issued by CILogon for the given audience ID (e.g., not the identity token keycloak generated after it has received CILogon authentication confirmation). Also, CILogon/Custos/Keycloak should be able to validate the identity token Galaxy has presented AWS (see steps 15 and 16 on Figure 4 in our manuscript https://doi.org/10.1101/506238). <https://doi.org/10.1101/506238> Do I need a Galaxy install to test it, or could I just use > https://github.com/galaxyproject/cloudauthz directly? If you have implemented means of getting id tokens from CILogon/Custos/Keycloak, you should be able to use CloudAuthz directly. Best, _____________ *Vahid Jalili, *Ph.D. Postdoctoral Scholar Computational Biology Institute Oregon Health and Science University 2730 SW Moody Ave, KCRB #3103.20, OHSU-RLSB Dock 61, Portland, OR, USA 97201 Skype ID: v.jalili On Fri, Feb 22, 2019 at 12:54 PM Basney, Jim <[email protected]> wrote: > Hi, > > I read the "Cloud Bursting Galaxy" paper (https://doi.org/10.1101/506238). > It helped a lot with my understanding, but I still have some basic > questions about how to set up the AWS trust relationship. The paper has > this example: > > { > "Version": "2012-10-17", > "Statement": [ > { > "Effect": "Allow", > "Principal": { > "Federated": "accounts.google.com" > }, > "Action": "sts:AssumeRoleWithWebIdentity", > "Condition": { > "StringEquals": { > "accounts.google.com:aud": "8936...apps.googleusercontent.com" > } > } > } > ] > } > > I think it means that Galaxy can assume the role for anyone who logs in to > Galaxy with a Google account (because the id_token audience matches the > Galaxy client_id registered with Google). Shouldn't the role be restricted > to a specific set of Google accounts via a condition on > "accounts.google.com:sub" or do we trust Galaxy to manage per-user access > to that role? > > To configure the role to accept CILogon/Custos/Keycloak id_tokens, > https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-idp_oidc.html > makes me think we just replace "accounts.google.com:aud" with > "cilogon.org:aud" or "iamdev.scigap.org:aud" following the > "server.example.com:aud" pattern. Anyone want to help me test that > scenario? Do I need a Galaxy install to test it, or could I just use > https://github.com/galaxyproject/cloudauthz directly? > > Thanks, > Jim
