This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.

I'm quite lost here
Is there any reason why we can't stick with the old and simpler implementation?
I thought that it was the right way to go, and also tried to understand why we are still looking for answers..., but i don't really get it
Keep it up with the good work , i'll try to join you as soon as i understand where we are.
REgards,

Comment

Is there any reason why we can't stick with the old and simpler implementation?

Well with the current approach we are duplicating the configuration information necessary to secure methods and to determine whether methods are secure. First we secure the methods using @Security annotations or intercept-methods tags (Or perhaps pointcuts), and then we have to respecify that information when configuring the MethodInvocationPriviligeEvaluator. If we try to support pointcut expressions, then this becomes especially hairy.

So for example if we use a intercept-methods tag within a bean declaration, we've already told Spring what roles are required to execute a certain method on a specific bean. We should now be able to do isCallable(Object, methodName) without adding further configuration.

I thought that it was the right way to go, and also tried to understand why we are still looking for answers..., but i don't really get it

Another thing is that we are creating and configuring another AccessDecisionManager and voters with our current design (At least with Spring 2.0 / 3.0 when using the security namespace). Spring needs these objects to do the method authorization check, so when I'm configuring them again for the MethodInvocationPrivilegeEvaluator, I'm creating them all over again...

Keep it up with the good work , i'll try to join you as soon as i understand where we are.

Diddo! I'm going to attempt to write up some design notes. Hope to have some stuff up soon .

Comment

OK - I think an elegant solution is to create a namespaced AuthorizationService implementation. Something like:

<security:authorization-service id="authorizationService">

The bean builder for this would take take care of looking up all the classes that it requires, such as the authentication service, access decision manager, etc. That way these won't have to be duplicated in the configuration file, and it's a lot cleaner.

Also I think creating the Map<Object, MethodSecurityInterceptor> might not be that difficult (Knock on wood >> my head).

I'm assuming the following is possible:
We can assign an ID to to each MethodSecurityInterceptor instance that allows it to be retrieved from the container the same way BeanDefinitionBuilder instances get the default AccessDecisionManager instance from the container.

We'll have this tag:
<security:authorization-service id="authorizationService">

create a Map<Object, MethodSecurityInterceptor> reference handle and corresponding instance. Then the BeanDefinitionParser for the intercept-methods tag will add each object and corresponding MethodSecurityInterceptor to the map (I'm hoping that's possible).

The the rest should be easy. I'll let you know in a few years if I manage to figure out the namespace stuff

The thinking here only covers the intercept-methods tag, but I once that's tackled, how to handle pointcuts and security annotations will be much clearer as well.

In the unit tests I pass the ClassPathXmlApplicationContext instance as the BeanFactory that's necessary to initialize the objectToSecureMethodInterceptorMap reference. So this needs some tweaking in order to make it work in a web context. I think all that's necessary is to lookup the factory like this: