Pluggable auth tokens about sregistry

[vsoch]

I might need a little more verbosity in your description (I don't know what an api management layer entails, or the external authority) but the way it works now is the following:

• an admin (aka a user given some permission to push / build) is given a token. The token is downloaded with a secrets file to his or her machine, and the file found via an environment variable.
• the token is used as a secret to generate an encrypted header (includes other things like timestamps, etc) that is un-encrypted by the server, and we check that the timestamp is within the minute (so it expires in that time), that the username matches the request user, and that the request content and pattern of the header matches the request. For details see:
• https://github.com/vsoch/singularity-python/blob/development/singularity/registry/client/auth.py
• https://github.com/vsoch/singularity-python/blob/development/singularity/registry/auth.py

These libraries will be updated with singularity 2.4 and the next version of singularity hub, for now they live in development branch.

So, if you wanted to grant access to push, you would just grant the token and you would trust they would use it securely, and have means to change their admin status (to prevent building) at any time.

For pull, you don't need to give tokens - you can do it with singularity shub:// endpoint, and just add the registry to the uri.

[vsoch]

I tried out JWT for sregistry but I didn't like it, so I came up with this schema that is similar to how Github deals with requests.

[vsoch]

depending on how this gateway works, you could also create the account for the user on the registry and then have your intermediate manager handle/ manage the token and then expose whatever common entrypoint you have for the user. That might be more secure than giving out tokens directly, although they are never actually passed in headers, just the content they help make.

[deardooley]

I think the issue is that I'd like to expose the sregistry API behind an existing api gateway so I can enforce standard usage policy, issue and track client applications, and enforce access control in our existing auth layer. Our identity providers are already in place and sregistry would ideally plug into those or simply extract the user identity and permissions from an auth header similar to what it is doing now. We are currently injecting a JWT into the request header once the request has been authorized at the api gateway layer, and forwarding it onto our backend services. The benefit being that we don't have to expose user credentials to 3rd party services, yet they can still securely consume user identity and authorizations through a standards-based mechanism.

If I am understanding your response correctly, with the current code base, I would need to:

1. Write an intermediate service and configure it with sregistry admin credentials
2. Configure the api gateway to forward all sregistry requests to the intermediate service
3. Have the intermediate service interpret the requests
4. Create, cache, or fetch sregistry delegation tokens based on the user entitlements as specified by sregistry
5. Forward the request on to sregistry

How would I go about impersonating a user request in sregistry? User credentials are never visible to anything but the oauth server, which we may or may not control. Is there a mechanism for generating a request header for another user in a secure, auditable way?

[vsoch]

If it helps I can review the use case that this implementation was intended for, and then we can figure out how to extend for your goals. Without an API gateway:

• any public image is findable (via API) and download-able /usable without needing to authenticate.
• a user can choose to log in with standard OAuth2 to get basics like stars, and anything that isn't exposed publicly. This is very flexible to providers, and this is why it's set up to turn on / off popular ones in the settings (and additional can be added if/when asked for)
• the only case of needing true "I can push images >> master admin" status (this token business we are talking about) is given that the user has the role "admin" - which must be granted by the superuser of a registry. This is very different than most platforms where you register --> get token, because it fits the use case where some small number of cluster admins are the only ones that should be given build ability, and then users can pull /use.

This use case you are describing:

I think the issue is that I'd like to expose the sregistry API behind an existing api gateway so I can enforce standard usage policy, issue and track client applications, and enforce access control in our existing auth layer.

is different I think - it assumes that every user must be tracked / authenticated. Why is this desired functionality - is the desire to want any authenticated user to have permission to push images? Is that a good idea? Note that if you want basic logging of who is requesting, sregistry has an internal module to do that see here.

Our identity providers are already in place and sregistry would ideally plug into those or simply extract the user identity and permissions from an auth header similar to what it is doing now.

Could you clarify how your entity provider works? I assume the action desired would be to push an image. Here are some ideas:

1. Create an authenticated "push" endpoint based on user

This first idea is to have your users register (with their account of choice) in the web interface (and registering wouldn't let them push or have advanced permission), and then you could approve the registration (and we could set up some kind of hook or notification). Upon approval, the user would be given the role to push. Either the approval would send back a secret (used to encrypt further communication, meaning secrets on the level of the user) or I could create an endpoint that accepts a header that includes the user and a similar header, but generated with a server secret (from your gateway, used for all users). In this idea, your API gateway would hold the user secrets, as opposed to the user.

2. Same, but give user secret

The second idea is to have the user's register, receive notification at your gateway, and then when they get an admin account THEY are notified to download the secret to where pushing will happen. Then their request goes to your API Gateway, they are the ones that use the sregistry command line tool to generate the request, and then you simply authenticate with your method and pass it on.

I realize now that you might not have tried out or read the docs completely - just to be clear, there is an sregistry client (and python functions) that handle the entire process of finding the token for a user and generating the header, and making the request. Then it is of course validated.

We are currently injecting a JWT into the request header once the request has been authorized

Can you tell me about this JWT header? It would be good to describe all steps of this authentication so I understand - something like:

• the user logs into the TACC web portal
• an OAuth2 token/refresh is granted and... sent to the API gateway?
• What happens at the API gateway? The request is authorized? (how?)
• how is the JWT header generated? Where does it go, and how is it checked?

at the api gateway layer, and forwarding it onto our backend services.

What does this mean? Is a backend service a third party thing, or a TACC thing?

The benefit being that we don't have to expose user credentials to 3rd party services, yet they can still securely consume user identity and authorizations through a standards-based mechanism.

Understood, this is why I generate the secret from the user, and only allow log in with OAuth2.

so given that a user registers with some OAuth2 provider via sregistry, and then given that a token (not the OAuth2 token, but a secret associated with the user) is passed to your endpoint that links to it, wouldn't you be able to 1) get a request from a user (however you do), 2) authenticate and forward the request using singularity-python to generate the appropriate header/metadata with the addition of the user token in the header, and then 3) get the response for approve /deny? What I don't want to do is have a two step "get permission sent back" and then "do push request" because there could be some weird interception. So the request being forwarded would include the image, and then it's either approved or denied.)

If I am understanding your response correctly, with the current code base, I would need to:

Write an intermediate service and configure it with sregistry admin credentials

This already exists, you would just use it. You download a json file, export the environment variable, and then you could use the internal python functions for the client, or the client directly. What would make sense is to have a client register directly with sregistry, get it approved by you, and then they download a file and have it exported in the environment and put into the request to your API gateway automatically. That way, the request passes through without you needing to do anything but forward it on, and approve the initial account.

Configure the api gateway to forward all sregistry requests to the intermediate service
Have the intermediate service interpret the requests
Create, cache, or fetch sregistry delegation tokens based on the user entitlements as specified by sregistry

These wouldn't be necessary given 1. The "intermediate service" is the client, and the header is generated when they run the command to push.

Forward the request on to sregistry

From your api gateway you would need to forward the request. We would also need to customize the singularity-python functions to direct to your gateway first instead of sregistry, and then your gateway to sregistry.

How would I go about impersonating a user request in sregistry?

You would need to have their computer / server with the file. If you somehow intercepted a request, the token wouldn't work because it integrates a timestamp and is specific to the call.

User credentials are never visible to anything but the oauth server, which we may or may not control. Is there a mechanism for generating a request header for another user in a secure, auditable way?

I think the approach to generate it with singularity-python when the request is made, on the user's computer / server, makes most sense.

[vsoch]

The Push API (both regular and library) now use standard Authentication headers with a user token, so I think it's safe to close this issue.