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

OpenID Connect: make used claim for a policies subject configurable #507

Closed
w4tsn opened this issue Oct 4, 2019 · 2 comments
Closed

OpenID Connect: make used claim for a policies subject configurable #507

w4tsn opened this issue Oct 4, 2019 · 2 comments

Comments

@w4tsn
Copy link
Contributor

w4tsn commented Oct 4, 2019

To make the new OpenID Connect feature (from ditto 1.0.0-M1) more useful there should be a way to configure or use groups and roles supplied within the JWT provided by the OpenID Connect-provider for checks against the subjects of a policy.

An example provider featuring claims specifically for authorization purposes is keycloak where you may receive groups and roles assigned to an authenticated user.

According to my conversation with @jokraehe about the OpenID Connect feature it is currently not possible to use other information provided in the JWT then the subject-claim within a policies subject.

Proposal

I propose to make it possible via configuration of an OpenID Connect provider in the gateway service to set a different claim as the used subject claim.

  1. If the selected claim is a string, it should be used as is.
  2. If the selected claim is an array, it should be treated as multiple subjects in a policy.
  3. If it's something else it should be ignored an error logged.

I think this would be a fairly easy way of enhancing the OpenID Connect capability without implementing a whole client. The client may follow in a subsequent approach.

Why

Being able to use another claim from the JWT increases flexibility and enables different scenarios e.g. role based policy management. It also hands over more control to authorization to the OpenID Connect provider, which in case of keycloak would be a desired state.

What do you guys think?

Implementation

If I find myself some spare time I'd like to start implementing this - Where should I start and what are likely issues I'll encounter on the way?

@w4tsn
Copy link
Contributor Author

w4tsn commented Oct 9, 2019

This is related to #512

@w4tsn
Copy link
Contributor Author

w4tsn commented Nov 11, 2019

This is actually a duplicate of #512 or the other way around :)

@w4tsn w4tsn closed this as completed Nov 11, 2019
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

1 participant