Skip to content

Add a basic authorization server policy for scope validation #187

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

Closed
Clem69B opened this issue Jan 6, 2021 · 3 comments
Closed

Add a basic authorization server policy for scope validation #187

Clem69B opened this issue Jan 6, 2021 · 3 comments
Assignees
Labels
status: duplicate A duplicate of another issue

Comments

@Clem69B
Copy link

Clem69B commented Jan 6, 2021

Expected Behavior
The RCF 6749 contains this proposal :

The authorization server MAY fully or partially ignore the scope requested by the client, based on the authorization server policy or the resource owner's instructions.
(https://tools.ietf.org/html/rfc6749#section-3.3)

A basic policy may be avaible, in order to filter scopes asked by client regarding the GrantedAuthority of the authenticated user (ressource owner) before the consent (in case of authorization_code with consent procedure).

Current Behavior
No comparaison or filtering are made between user GrantedAuthority and scope asked by the client.
So tokens are delivered regardless of the user rights limitation.

Context
I have a custom UserDetailsService and authorities specified with authorized scope for the user.

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Jan 6, 2021
@jgrandja
Copy link
Collaborator

jgrandja commented Jan 6, 2021

@Clem69B There are many generalized recommendations in RCF 6749, this being one of them:

The authorization server MAY fully or partially ignore the scope
requested by the client, based on the authorization server policy or
the resource owner's instructions.

The preceding statement does not translate to:

A basic policy may be avaible, in order to filter scopes asked by client regarding the GrantedAuthority of the authenticated user (ressource owner) before the consent (in case of authorization_code with consent procedure).

I do understand the need for custom policies but this would be custom functionality that would be implemented in an OAuth 2.0 Provider product. This project is strictly focused on implementing the various OAuth 2.0 / OIDC specifications.

This custom behaviour (policy enforcement) would need to be implemented in an OAuth 2.0 Provider product that ultimately extends from this project / framework.

I hope this makes sense?

@jgrandja jgrandja closed this as completed Jan 6, 2021
@jgrandja jgrandja self-assigned this Jan 6, 2021
@jgrandja jgrandja added status: declined A suggestion or change that we don't feel we should currently apply and removed status: waiting-for-triage An issue we've not yet triaged labels Jan 6, 2021
@Clem69B
Copy link
Author

Clem69B commented Jan 6, 2021

Hello @jgrandja,

Thanks for your answer, it's make sense regarding this ticket name and description.

But, the reason behind this ticket is still actual, and, I think, focus on your project : If I want to do this myself, how can I do it with this framework ? What are the entry points ?

I have explored the source code, and actualy, I have seen no suitable method to do this, except rewrite a lot of things.

So I have written a specific ticket to be clear on my situation and my need, but I think that is a more global need and can be in the framework scope : How a third party integrator can build its own policy using your project ?

@jgrandja
Copy link
Collaborator

jgrandja commented Jan 6, 2021

@Clem69B I've noted this in #139

Provide plugin mechanism for Policy Enforcement

I'm capturing all possible extension points in that "umbrella" ticket.

@jgrandja jgrandja added status: duplicate A duplicate of another issue and removed status: declined A suggestion or change that we don't feel we should currently apply labels Jan 6, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: duplicate A duplicate of another issue
Projects
None yet
Development

No branches or pull requests

3 participants