Davide Romanini wrote:
Is this approch correct? Could someone give me some tip to satisfy my
requirements?
If I understand correctly, you need to X509 authenticate an actual
remote system, but BASIC authenticate the actual user that is using the
remote system?
In that case, you're best off to do it in as portable and reusable
fashion possible. That would mean:
- Use HTTPS with X509 Client Authentication so that all requests to the
web services end points require presentation of an X509 client certificate
- Present BASIC authentication headers in the request in standard
username/password format for the actual user
The above should be pretty easy to do. Remember your web container is
responsible for requesting an X509 client certificate, so you'll need to
configure it accordingly. As a review of
X509ProcessingFilter.extractClientCertificate() shows, we just access
the certificate from a HttpServletRequest. Rather than attempt to get
the Acegi Security X509 capabilities to work directly, I would instead
recommend that you write a new filter modelled on X509ProcessingFilter.
What it would do is only act if the
SecurityContextHolder.getContext().getAuthentication() is non-null. In
that case, you can assume the SecurityContextHolder represents an
appropriately authenticated user courtesy of BASIC authentication. Your
new filter will then simply obtain the X509 certificate and then call
SecurityContextHolder.getContext().getAuthentication().setDetails(new
X509WebAuthenticationDetails(httpServletRequest)). The
X509WebAuthenticationDetails is a new class you'll need to write that
subclasses WebAuthenticationDetails and uses its
doPopulateAdditionalInformation(HttpServletRequest) method.
This should give you some ideas on capturing and storing the
authentication. How to finish it off really depends on your need to
"authenticate" the X509 certificate or "authorize" based on it.
Specifically, your web container is responsible for initial X509
certificate acceptance as it happens during HTTPS establishment - Acegi
Security is too late in the game to make a difference there (though
obviously we can throw exceptions in objection, but that won't cause a
new HTTPS session to be started). You could possibly delegate to
existing X509 interfaces to form an Authentication object and put it
inside a special GrantedAuthority. Or, you could simply use a custom
AccessDecisionVoter - maybe X509AuthenticatedVoter - which looks for a
X509_ESTABLISHED configuration attribute and simply does the relatively
inexpensive check that Authentication.getDetails() can be cast to your
new X509WebAuthenticationDetails and contains a non-null X509
certificate. As you can see, there a few approaches you could use to
wrap up the authentication and authorization.
Let me know what you end up deciding. I am wondering if we should store
the X509 inside WebAuthenticationDetails as a standard feature and
perhaps offer a voter as described. Luke, any thoughts on that?
Cheers
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://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Home: http://acegisecurity.org
Acegisecurity-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
