Brian Moseley wrote:
where i'm stumbling is that BasicProcessingFilter immediately
authenticates the credentials it finds in the Authorization header,
and upon failure it commences its configured authentication entry
point. why does it do this? why doesn't it simply set up an
authentication token and let the SecurityEnforcementFilter handle the
authentication? that's what my TicketProcessingFilter does, and it
works fine (when the request contains only ticket credentials).
Hi Brian
BasicProcessingFilter proactively attempts authentication (via
AuthenticationManager) whenever it sees a BASIC authentication header,
which is consistent with the contract for an authentication mechanism
and the others included with Acegi Security. The reason they all attempt
authentication is to give the user early advice there is a problem with
presented credentials, even in the case the user isn't actually
requesting a secure object. For example, someone may present a BASIC
header but request a public home page. In that situation the
authentication mechanism would notify the user agent as early as
possible there has been an issue.
In your case we do have a few options:
- Provide a "failedAuthentication" method in BasicProcessingFilter so
you could subclass and override the default behavior. You'd probably
like to leave the SecurityContextHolder null and allow the FilterChain
to proceed. Your "ticket" filter would then have a chance to process the
request.
- Provide an "ignoreFailure" property, which essentially does the same
FilterChain continuation as the aforementioned option.
- Write your own authentication mechanism that reflects your particular
needs. You don't need to use the BasicProcessingFilter.
- Use BASIC authentication as a transport for your tickets. I'd probably
see this as the most elegant approach, if it were possible. Rather than
use a dedicated HTTP header, use a specific username to denote a ticket,
eg "TICKET". The password would be the actual ticket itself,
Base64-encoded as per standard BASIC authentication headers. Then you're
going to only need deal with all of this in your UserDetailsService
implementation. So you've also avoided needing to write an
AuthenticationProvider (and probably an Authentication implementation
and authentication mechanism as well). Plus you've picked up the benefit
of allowing migration (one day, if you like) to a form-based
authentication interface (debugging?), digest or similar authentication
that can also be carried in a simple username + ":" + password formatted
payload.
Thoughts?
Ben
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Home: http://acegisecurity.org
Acegisecurity-developer mailing list
Acegisecurity-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
