Super user feature refactor (JWTs only) about argus HOT 10 CLOSED

Are we wanting to support both JWTs and basic auth?

The path with JWTs seems straightforward: you configure bascule with the appropriate verifier to produce the super user "bit".

If we want to also support basic auth, then I would suggest for the first version to just assume anyone who submits basic auth is not a super user. Otherwise, you'd need to have some database or configuration that identifies the users who are super users. With a JWT, you can rely on signature verification to assure argus that the user is supposed to be a super user.

from argus.

Good question. JWTs would be sufficient for us internally but basic auth might help for opensource friends trying out Argus. I would vote for the super user through config approach just for consistency and as a way to let folks try out all the features with basic auth as well.

from argus.

1. Will there be multiple super user capabilities or one super user capability that will work for every argus endpoint?

2. Does it have to be used in coordination with another capability for the endpoint, or presumably if you have super user, we don't need to check for the other capability?

3. If the owner provided by a super user doesn't match the owner of that item, is that request valid? This allows a put request by a super user to change the owner of an item, and allows the super user to delete an item they believe belongs to someone else.

from argus.

To address @kristinaspring 's questions, these are my opinions

1. For now, I think there are only 3 permission sets - no permissions, regular user, super user
2. The super user permissions is a super set of regular user permissions.
3. I don't think this is a concern since the owner meta attribute should not be modifiable.

from argus.

Expanding on what JC replied:

1. Yeah, I'm thinking that no permissions == invalid JWT, regular user (valid JWT, no capabilities) and super user (valid JWT with capabilities). If we want to add capabilities even for regular users, we'd have to add a new part to capabilities that indicate permission level like :regular and :admin suffixes.
   Long context answer to say @kristinaspring that if we want to support use cases where we want to allow super users to list all items but not delete items, we would need one capability per endpoint. If we want to start simple (which is enough for our webhooks use case), we can just have one capability indicating super user powers 🔋 for all endpoints.

2. I think this depends on our answer to (1)

3. Yeah, for updates, changing the ownership of an item is off limits even as super user.

from argus.

Turns out I found a bug! 🐛 Made an issue related to my third question.

I talked with Joel some and we think it's possible / fairly easy to have capabilities for regular users and super users. Exactly what those capabilities will look like is still up for discussion, so I'm going to move on to a few other thoughts.

One thing to consider is that anyone in the open source community that wants to use this will have to create their own JWTs with a capabilities field in order to utilize super user functionality. In order to not force our friends to use capabilities, our other service have capability checking as a configurable option. I expect regular user capability checking will be configurable, but until we allow for super users through basic auth, super user functionality will only be available while also enabling capability checking, right? Just want to make sure we're happy with the short term consequences of delaying super user abilities outside of jwt.

What about when no authorization is being done (both basic and bearer auth not configured - presumably this only happens in a local setup)? Is every request a super user request? I assume that, similar to basic auth initially, it's not possible to have a super user request.

from argus.

Yay - thanks for finding that 🐛 . We'll crush it with a bug-a-salt!

Yeah, it seems reasonable to me starting with a world in which the super user feature only works with JWTs and where:

• No authentication enabled -> no super user feature
• Basic auth -> no super user feature

from argus.

Is there no way to map different basic auth users into different roles in Bascule?

from argus.

Bascule currently has no concept of roles (or trust). There is a way to do it without modifying current bascule code, or we can add it to bascule's Token or Authentication.

from argus.

This was fixed as part of #112

from argus.