Question about auth systems integrations opinions #546

New Issue

Open

opened 2023-04-20 10:45:49 +00:00 by maxkoko · 2 comments

maxkoko commented

2023-04-20 10:45:49 +00:00

I was thinking of mapping the bucket/token to a user managed by keycloak or one of the oAuth providers for now in some hacky way for now, but what would be the long-term approach you would envision?

Hi, I understand the decision not to make your own auth system, and I agree with it, but systems written around S3 will need more complex policy/auth/user management sooner or later. How would you like to integrate the token per bucket approach to some auth software, or how should someone go about it in your view? I was thinking of mapping the bucket/token to a user managed by keycloak or one of the oAuth providers for now in some hacky way for now, but what would be the long-term approach you would envision?

maxkoko closed this issue

2023-04-20 10:49:44 +00:00

maxkoko reopened this issue

2023-04-20 10:49:51 +00:00

quentin commented

2023-04-21 08:02:16 +00:00

Owner

Hi maxkoko,

(1) At deuxfleurs.fr we use LDAP to manage our users. We store their access key identifier in their profile, in a dedicated key. After that, we have an experimental (not ready for production) SFTP+WebDav proxy: https://git.deuxfleurs.fr/deuxfleurs/bagage that knows how to authenticate against LDAP and fetch the keys. The Garage key is generated by our administration interface (thanks to garage-admin-sdk-golang) and attached to the user's LDAP profile more or less during their first connection, the code is here: https://git.deuxfleurs.fr/Deuxfleurs/guichet/src/branch/main/garage.go#L112-L137

(2) Another option that has been recommended by NLnet to us is SASL. I don't know how we can implement SASL with Garage/HTTP but I plan to look at it a bit more in depth.

(3) A last approach that we thought of could be one inspired by https://remotestorage.io/. So something based on web finger and open id connect, and then you get the user's key.

Your proposition seems to be a mix of (1) and (3). If you implement it for real, do not hesitate to share your return of experience: it will be definetely valuable to us!

It is not clear what is the best solution yet, nor if and how such logic must be implemented in Garage. For now, probably that refining/better documenting the Garage API, providing guidelines and examples could be a good starting point?!

Hi maxkoko, (1) At deuxfleurs.fr we use LDAP to manage our users. We store their access key identifier in their profile, in a dedicated key. After that, we have an experimental (not ready for production) SFTP+WebDav proxy: https://git.deuxfleurs.fr/deuxfleurs/bagage that knows how to authenticate against LDAP and fetch the keys. The Garage key is generated by our administration interface (thanks to [garage-admin-sdk-golang](https://git.deuxfleurs.fr/garage-sdk/garage-admin-sdk-generator#user-content-golang)) and attached to the user's LDAP profile more or less during their first connection, the code is here: https://git.deuxfleurs.fr/Deuxfleurs/guichet/src/branch/main/garage.go#L112-L137 (2) Another option that has been recommended by NLnet to us is SASL. I don't know how we can implement SASL with Garage/HTTP but I plan to look at it a bit more in depth. (3) A last approach that we thought of could be one inspired by https://remotestorage.io/. So something based on web finger and open id connect, and then you get the user's key. Your proposition seems to be a mix of (1) and (3). If you implement it for real, do not hesitate to share your return of experience: it will be definetely valuable to us! It is not clear what is the best solution yet, nor if and how such logic must be implemented in Garage. For now, probably that refining/better documenting the Garage API, providing guidelines and examples could be a good starting point?!

quentin added the

Ideas

label 2023-04-21 09:45:18 +00:00

flokli commented

2023-07-16 10:54:50 +00:00

Contributor

I'd definitely be interested in something like OIDC, and being able to use your JWTs (or exchange it for something else) to talk to Garage.

In AWS, you can configure an OIDC Provider, and describe certain conditions (claims that need to exist and have certain values) to allow assuming an IAM rule. See https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect for an example.

I'd love if something similar would be possible with Garage. We probably don't want to re-implement half of IAM in there, but I'm more thinking about a separate component alongside Garage, that can do all this decision-making, and is able to issue short-lived, and tightly scoped credentials for Garage.

Garage would only need to provide an API to create these short-lived and limited tokens, and all the complicated decision logic could be implemented in a third-party thing. Bonus points if it's compatible with STS enough so that the native AWS client SDK could be used to obtain these from JWTs.

I'd definitely be interested in something like OIDC, and being able to use your JWTs (or exchange it for something else) to talk to Garage. In AWS, you can configure an OIDC Provider, and describe certain conditions (claims that need to exist and have certain values) to allow assuming an IAM rule. See https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect for an example. I'd love if something similar would be possible with Garage. We probably don't want to re-implement half of IAM in there, but I'm more thinking about a separate component alongside Garage, that can do all this decision-making, and is able to issue short-lived, and tightly scoped credentials for Garage. Garage would only need to provide an API to create these short-lived and limited tokens, and all the complicated decision logic could be implemented in a third-party thing. Bonus points if it's compatible with STS enough so that the native AWS client SDK could be used to obtain these from JWTs.

👍 1