John Lewis wrote:
- You are correct that the portlet container performs the
authentication and then provides a String username to portlets running
within the portlet container. It is very similar to CAS and X509 and
I modeled the code after those two quite a bit. Unfortunately, the
JSR-168 spec completely delegates the authentication to the
portlet-container and does not provide a standard way to plug an
authentication mechanism into it. Of course, a portlet container
implementation could use Acegi directly (I believe that the Gridsphere
team is considering this in the near future). I have not created a
default implementation of PortletAuthoritiesPopulator at this point.
The only authorities mechanism in JSR-168 is the same isUserInRole
method as in the Servlet spec. I suppose we could create a default
PortletAuthoritiesPopulator that could be configured with a list of
roles to check.
It seems a very common requirement for a separate system to authenticate
a user and provide only a String-based username to an application. This
is seen with CAS, X509, Portlets and a range of external authentication
services. Therefore, it would seem desirable to offer a generic
equivalent to CasAuthoritiesPopulator/X509AuthoritiesPopulator.
Cheers
Ben
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Home: http://acegisecurity.sourceforge.net
Acegisecurity-developer mailing list
Acegisecurity-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer