Why do you want to do that? It's a very atypical thing to do and sounds like an anti-pattern to me. Roles should be global and the application should act accordingly. Please provide more data on your use case.
–
jkraybillJul 28 '11 at 0:33

1

Agreed. Roles are part of a user's security context and should only be updated either by 1) admin updates, or 2) a permanent change in the user's profile, such as removing a product. Why would you want to do this?
–
atrainJul 28 '11 at 2:29

Thanks for the feedback, What I'm trying to do is to validate username and password each time the user hits "/auth/**" psth. so the authentication should be done twice, once for "/" and each time the /auth/** hits. So can you please help me to find alternative way to do that?
–
danny.lesnikJul 28 '11 at 6:32

2 Answers
2

I would like to revoke "ROLE_ADMIN" authority from the user when he navigates out of "/auth/**" zone.

How can I achieve such functionality? Can I put some kind of filter on all URLs except /auth/** which revokes Authority from the user?

Can I revoke it "on the fly"?

I think you are misunderstanding the meaning of the intercept-url element:

<security:intercept-url pattern="/auth/**" access="ROLE_ADMIN"/>

This does NOT say "grant the user ROLE_ADMIN in the /auth/** tree". It says, "a user who hasROLE_ADMIN is allowed to access pages in the /auth/** tree".

The idea that a user's role changes depending on what he / she is looking at is strange, to say the least.

What I'm trying to do is to validate username and password each time the user hits "/auth/**" psth.

OK, that kind of makes sense as a requirement. (Though, as a hypothetical user I would find it mysterious and/or annoying that simply navigating around the site cause me to be logged out.)

But I don't think you should do that by changing the user's role(s) on the fly. If you do that you are liable to get "Permission denied" responses instead of redirects to the login page.

What you really need to do is to put them back into the "not logged in" state. But even that can be a bit tricky. If pages in the /auth/** tree have links to stylesheets or script files, then when the browser fetches those links the security filters are liable to think that the user has navigated out of the /auth/** tree and log him out.

RevokeAuthRoleFilter better to define after securityContextPersistenceFilter that populates and clears Application context. Than in your custom filter you will be able to get access to Authentication object through SecurityContextHolder and to change its authorities.