Skip to content

Authorization Manager Method Security #9630

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

Merged

Conversation

jzheaux
Copy link
Contributor

@jzheaux jzheaux commented Apr 13, 2021

No description provided.

@jzheaux jzheaux force-pushed the authorization-manager-method-security branch 3 times, most recently from 2adbf47 to 396ab87 Compare April 19, 2021 22:08
Copy link
Member

@rwinch rwinch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've provided some feedback. I think we should also ensure we are addressing issues around what to do if multiple annotations are present. A few examples are:

Copy link
Member

@rwinch rwinch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've provided some additional feedback inline. I also think we need to ensure we address #9630 (review)


/**
* Returns an {@link AuthorizationManager} for the
* {@link AuthorizationMethodInvocation}.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AuthorizationMethodInvocation does not exist, so please remove references to it

* @see SecuredAuthorizationManager
* @see Jsr250AuthorizationManager
*/
public final class AuthorizationAdvisors {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this could be removed in favor of constructors on the *Interceptors that match the static methods. We could put the DEFAULT_ORDER constant on the *Interceptor instances and default the value to it. Doing this would mean the users who customize the *Interceptors wouldn't need to remember to set the value to the default.

It would also make things a bit more consistent. The use of these constants seems inconsistent. PRE_FILTER_ADVISOR_ORDER is used by PreFilterAuthorizationMethodInterceptor directly. However, PRE_AUTHORIZE_ADVISOR_ORDER is only used in AuthorizationAdvisors.

@jzheaux jzheaux force-pushed the authorization-manager-method-security branch from 74e1e47 to 04d8184 Compare April 28, 2021 04:06
Copy link
Member

@rwinch rwinch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall it looks good. I've provided some comments inline. Can we close the related issues and use this to supersede now? I think we should also add XML support

@PreAuthorize("hasRole('USER')")
Account[] findAccounts();

@PreAuthorize("hasRole('TELLER')")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Spacing issues here?

[source,java]
----
@Bean
MethodSecurityExpressionHandler methodSecurityExpressionHandler() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

make this method static as it will be initialized very early on for AOP and static methods ensure that only this method is invoked vs initializing the entire configuration class

@@ -6,6 +6,213 @@ It provides support for JSR-250 annotation security as well as the framework's o
From 3.0 you can also make use of new <<el-access,expression-based annotations>>.
You can apply security to a single bean, using the `intercept-methods` element to decorate the bean declaration, or you can secure multiple beans across the entire service layer using the AspectJ style pointcuts.

=== EnableMethodSecurity

In 5.6, we can enable annotation-based security using the `@EnableMethodSecurity` annotation on any `@Configuration` instance.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it is worth describing how this differs from @EnableGlobalMethodSecurity and that users should prefer this new support.


In 5.6, we can enable annotation-based security using the `@EnableMethodSecurity` annotation on any `@Configuration` instance.

[NOTE]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similar to how how we use { for if blocks, we use ==== for admonitions

@@ -6,6 +6,213 @@ It provides support for JSR-250 annotation security as well as the framework's o
From 3.0 you can also make use of new <<el-access,expression-based annotations>>.
You can apply security to a single bean, using the `intercept-methods` element to decorate the bean declaration, or you can secure multiple beans across the entire service layer using the AspectJ style pointcuts.

=== EnableMethodSecurity
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please add a reference to this in What's New

@@ -6,6 +6,213 @@ It provides support for JSR-250 annotation security as well as the framework's o
From 3.0 you can also make use of new <<el-access,expression-based annotations>>.
You can apply security to a single bean, using the `intercept-methods` element to decorate the bean declaration, or you can secure multiple beans across the entire service layer using the AspectJ style pointcuts.

=== EnableMethodSecurity

In 5.6, we can enable annotation-based security using the `@EnableMethodSecurity` annotation on any `@Configuration` instance.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps change to "In Spring Security 5.6"

Copy link
Member

@rwinch rwinch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @jzheaux The changes look good to me. We will get this into 5.6 right after 5.5 goes ga

@rwinch rwinch added this to the 5.6.0-M1 milestone May 4, 2021
@rwinch rwinch added in: core An issue in spring-security-core type: enhancement A general enhancement labels May 4, 2021
@jzheaux jzheaux force-pushed the authorization-manager-method-security branch from c5515b9 to 041fce8 Compare May 4, 2021 22:41
evgeniycheban and others added 2 commits May 18, 2021 17:06
- Removed consolidated pointcut advisor in favor of each interceptor
being an advisor. This allows Spring AOP to do more of the heavy
lifting of selecting the set of interceptors that applies
- Created new method context for after interceptors instead of
modifying existing one
- Added documentation
- Added XML support
- Added AuthorizationInterceptorsOrder to simplify interceptor
ordering
- Adjusted annotation lookup to comply with JSR-250 spec
- Adjusted annotation lookup to exhaustively search for duplicate
annotations
- Separated into three @configuration classes, one for each set of
authorization annotations

Issue spring-projectsgh-9289
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core An issue in spring-security-core type: enhancement A general enhancement
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants