Hi John I've been hacking something together, implementing the suggestion I've made in my previous mail (see attachment). I am wondering what the best strategy is to notify the user about the rights he's missing. If we're handling a render request, no problem - but what if it's a portlet request?
Here's an example config, too:
<bean id="authenticationHandlerInterceptor"
class="net.swisstech.portlet.security.interceptor.AuthenticationHandlerInterceptor">
<property name="authData">
<value>
mode:edit=editor
action:delete*=deleter
*=user
</value>
</property>
</bean>
I am aware that this is totally outside of acegi itself and it's
actually only related to spring portlet...
While debugging, I've seen what the Principal returned by
PortletRequest.getUserPrincipal() actually is and that it does contain
a list of roles and all so we could even create a UserDetails object
from that and use the cool RoleVoter etc. But it'd probably require a
class to extract these data (if at all accessible) for every different
implementation of java.security.Principal.
Or is it possible, when the portal's servlet security is managed by
acegi, to replace the Principal in the request by an
org.acegisecurity.Authentication?
Or, as long as we're staying in the same VM, a UserDetailsService
could retrieve the authenticated servlet-user directly from the
SecurityContextHolder and use that as portlet-user.
Patrick
2005/12/13, Patrick Huber <[EMAIL PROTECTED]>:
> Hi John
>
> I just started looking at your implementation. I've refactored it and
> merged into my local copy of the acegi source snapshot dated
> 2005-12-11.
>
> The use of a AuthenticationDao (or UserDetailsService in 0.9) makes me
> wonder. I'm assuming the container to take care of authentication and
> I do not store user data except for the user id in order to associate
> application data with an authenticated user.
>
> Am I misunderstanding the concepts behind your prototype?
> My Point is, that I don't want to manage user data myself let alone
> prompt the user to enter his credentials (for each portlet).
>
>
> I'd do it all something like this:
> - Define which portlet modes or action attributes (see
> portletModeParameterHandlerMapping and portletModeHandlerMapping from
> spring portlet) require which role. So we get per-mode and
> per-controller granualarity. Method level granularity like you in your
> example config should still be possible.
> - Then add an interceptor to the HandlerMapping. The Interceptor
> analyses what target portlet-mode or controller this request has,
> reads what role is required for that controller and verifies that the
> user does actually have this role by calling
> PortletRequest.isUserInRole().
> - If the user does not have one of the required roles, abort and
> display an error message.
>
> Like this, we can entirely rely on the portal's sso mechanism and
> don't have to bother with daos and user details.
>
> In the above suggestion, we could neither use a RoleVoter nor Acegi's
> Authentication since all this relies on UserDetails.getAuthorities().
> And I don't see a way to retrieve the granted authorities from the
> PortletRequest so we could create our own Authentication and reuse the
> RoleVoters etc.
>
> What do you think about this idea?
>
> I will send you the code I've refactored in a separate mail.
>
>
> Patrick
>
>
> 2005/11/5, John Lewis <[EMAIL PROTECTED]>:
> > Ken & Patrick,
> >
> > I've developed some initial JSR-168 Portlet support for Acegi.
> >
> > It is a separate provider with its own implementation of
> > AbstractAuthenticationToken, AuthenticationProvider, UserCache, etc.
> > I've also provided a PortletSessionContextIntegrationInterceptor and
> > PortletProcessingInterceptor.
> >
> > One of the unique challenges of portlet development in this space is
> > that filters are not applied to portlet requests, so none of the
> > existing filter-based can be used with the portlets. But with the two
> > interceptors above I think it covers the basics and allows for use of
> > MethodSecurityInterceptor and for the taglib in JSP content.
> >
> > The main thing that is missing at this point is an equivalent of the
> > URL-based security mechanisms such as FilterSecurityInterceptor. Since
> > portlet requests don't include traditional URLs, this is difficult to
> > translate. I think the best thing here will be to implement something
> > parallel to the HandlerMapping classes that allows security to be
> > applied in the same way.
> >
> > I've posted the classes and some example application context entries on
> > the Spring Portlet Wiki site. You can download the file here:
> >
> > http://opensource2.atlassian.com/confluence/spring/download/attachments/10/acegi-portlet.zip
> >
> > At this point it is integrated with Acegi 0.8.3 and needs to be
> > refactored for integration with 0.9.0.
> >
> > I'm very interested in your feedback. Let me know what you think.
> >
> > John Lewis
> >
> >
> > Ballard, Ken wrote:
> >
> > >Hi,
> > >
> > >I'm pushing for my company to use Acegi. At some point my company will
> > >probably start using JSR-168 portlets and it would help if I could show
> > >that
> > >Acegi's security framwork will work with a portal application (probaly
> > >WebSphere or JetSpeed). Will Acegi support this?
> > >
> > >Thanks,
> > >Ken
> > >
> > >
> > >
> >
> >
> > -------------------------------------------------------
> > 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
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
> >
>
>
> --
> "I love deadlines. I like the whooshing sound they make as they fly
> by." -- Douglas Adams
>
--
"I love deadlines. I like the whooshing sound they make as they fly
by." -- Douglas Adams
AuthenticationHandlerInterceptor.java
Description: Binary data
