Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue with Auth in Singularity 1.2.0 #2134

Closed
yuriy-filatov opened this issue Sep 24, 2020 · 4 comments
Closed

Issue with Auth in Singularity 1.2.0 #2134

yuriy-filatov opened this issue Sep 24, 2020 · 4 comments

Comments

@yuriy-filatov
Copy link

yuriy-filatov commented Sep 24, 2020

Hey
We're currently adding another layer of security into our current cluster, but have already faced several issues.
We've managed to add webhook into our, I'd say, thingy, which is serving login page and goes into LDAP for user verification.
Output is pushed into cookie and passed to Singularity.
First issue -- we were unable to feed that to Singularity through header, 'cause js scripts which are 'talking' to api were ignoring forwarded authorization header and used null instead -- that's why we've used cookie wrapping.
Second -- any emailed action doesn't have singularityUserId anymore (actually this is a long-runner, unrelated to current issue and is observed at least for last 12 months). Can singularityUserId be also parsed from http://URI/singularity/api/auth/user from user:id field if auth is enabled?

And the main issue is that I don't get how groups are working.
Users who are enrolled into jitaGroups+requiredGroups are unable to browse UI at all, everything blows up with something like

An error occurred while accessing /requests/ids?useWebCache=true&state=ACTIVE&state=PAUSED&state=SYSTEM_COOLDOWN&state=FINISHED&state=DEPLOYING_TO_UNPAUSE

Unable to authenticate using methods: [SingularityWebhookAuthenticator (Exception while verifying token: java.lang.RuntimeException: javax.ws.rs.WebApplicationException: HTTP 401 Unauthorized)]

Although everything is working as intended (I mean -- whole our machinery with blows and whistles).

Users who are enrolled into globalReadOnlyGroups+requiredGroups are able to pause/unpause jobs and edit anything (wut?).
Users who are enrolled into adminGroups+requiredGroups -- can do pretty much the same as RO users do.

Can you please clarify how this feature is working (or not)? Can we assign more granular rights to groups? Thanks!

@ssalinas
Copy link
Member

So there is a bunch here and I can provide a more detailed response tomorrow. but some shorter highlights:

  • I totally acknowledge Singularity auth was an afterthought. As an internal-only tool it went from totally open for a small team of engineers to trying to figure out how to mesh an oss project with our internal home-built auth system
  • We recently added more granular permissions and updated how Singularity does its checks a bit in Rework auth to include scopes as well as groups #2092 . tl;dr on that one is that originally the old auth was aimed at 'is this person at least allowed to be in Singularity'. The options aren't quite as granular as I would want, but at least allow it to distinguish read/write/admin scopes on top of existing groups. (i.e. fixes the anyone in a valid group can do stuff issue). This will be in a 1.3.0 andI can try and get a public release out soon-ish if you're interested

@yuriy-filatov
Copy link
Author

Great news, thank you!
We'd happy to test new release as soon as it will be available 😄

@ssalinas
Copy link
Member

ssalinas commented Oct 1, 2020

1.3.0 jars should be on maven central in a bit, just released. Gonna close this one for now and we can open new/specific issues as they pop up 👍

@ssalinas ssalinas closed this as completed Oct 1, 2020
@yuriy-filatov
Copy link
Author

Amazing, thank you!
We'll start testing asap.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants