I just reposted the code and have included a
DaoPortletAuthoritiesPopulator which is essentially a duplicate of
DaoCasAuthoritiesPopulator.
Thanks again for the feedback!
John
Ben Alex wrote:
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
