[EMAIL PROTECTED] wrote
How do I get around this? I can see 2 ways - either having something like:
<property name="accessDecisionManager"><ref bean="accessDecisionManager"/></property>
<property name="objectDefinitionSource">
<value>
CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
PATTERN_TYPE_APACHE_ANT
/security/**=
/**=ROLE_ALLOWED_USER
</value>
</property>
</bean>
but this doesn't seem to work, or better still, being able to give the Anonymous user a role. This allows configuration of what the anonymous user can do on a per-implementation basis of an application.
Have I missed something in the config, or can this not be done yet?
Hi Steve
This is presently not possible. There are two main ways it could be done:
AbstractSecurityInterceptor gets new code after its if (attr != null) and debug message. The new code iterates attr and if it finds any "anonymous" property, it immediately calls callback.proceedWithObject(object). The problems with this approach include the ContextHolder may be null or not contain a SecureContext, any Authentication object on it may be incorrect, and no run as replacement may take place. This is because these capabilities are part of AbstractSecurityInterceptor and rely on the SecureContext being on the ContextHolder, which for truly anonymous users is not possible. For securing HTTP requests these issues are somewhat benign, but a major problem if any invocations take place to business objects that want to check the ContextHolder or require elevated permissions.
The alternative (better) approach is to write a filter that checks for a HttpSession attribute keyed against HttpSessionIntegrationFitler.ACEGI_SECURITY_AUTHENTICATION_KEY. If it is null, create an Authentication object with a username and password acceptable to your authentication manager. This will in turn be populated onto the ContextHolder by the AutoIntegrationFilter or HttpSessionIntegrationFilter (your choice). The benefit of this approach is there aren't any "magic" keywords, stronger security is offered due to full execution of the Acegi Security stack, and you can have different types of anonymous users for different areas of your application. On a less positive note, the AbstractSecurityIntercetor will not be able to tell between this "automatic" Authentication object and a "real" Authentication object. Being unable to distinguish, it will always see a valid Authentication object and thus never throw a AuthenticationCredentialsNotFoundException. This will mean you cannot have the webapp automatically guide the user into logging in. Instead you'll need some sort of advanced handling of an AccessDeniedException, as it might genuinely be access denied or it might simply be the user hasn't logged in properly. This is normally handled by SecurityEnforcementFilter sending a 403 code. You might like to subclass SecurityEnforcementFilter and have it automatically clear the HttpSession attribute and redirect to a login page (in the event of an "automatic" Authentication object) or send the 403 if they're already logged in.
As you can see, it's not as black and white as it first appears. You'd probably have less work to simply make your request URIs reflect the sample application. ie:
/* = not secured (also where login form lives) /some_subdirectory/* = secured
HTH Ben
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Acegisecurity-developer mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
