portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Deepak Kaimal <dkai...@trestlellc.com>
Subject RE: Jetspeed Authorization
Date Wed, 19 Aug 2009 21:15:23 GMT
Thank you for your response and I hope you enjoyed your vacation, I am sure it was well earned.

My aim was to create a Policy Enforcement Point (PEP) for J2 with the OpenSSO server acting
as the PDP and PAP. As we progressed, we realized that the authorization components are distributed
within the J2 codebase and because of the different kinds of authorization modes supported,
it is not easy to pull just that component out.

We have decided that letting J2 manage authorization internally is probably more robust and
performance optimized since there is no easy and manageable way to plugin a new authorization

Overall, I am now of the belief that authentication can be centralized, but authorization
is best handled natively.

Thanks and Regards,
Deepak Kaimal

-----Original Message-----
From: David Sean Taylor [mailto:d.taylor@onehippo.com] 
Sent: Wednesday, August 19, 2009 2:29 PM
To: Jetspeed Developers List
Subject: Re: Jetspeed Authorization

On Jul 28, 2009, at 8:20 AM, Deepak Kaimal wrote:

> We are in the process of trying to integrate Jetspeed2 with OpenSSO  
> for both Authentication (SSO) and Authorization. We have been  
> successful in the authentication piece, but I have not been able to  
> figure out how to switch out the authorization piece.
> We are trying to get Jetspeed2 to delegate authorization checks for  
> a portlet action (View, Configure etc.) to OpenSSO before the  
> portlet is rendered on the page. In the process of analyzing the  
> code, I was able to make certain changes to the  
> org.apache.jetspeed.security.impl.SecurityAccessControllerImpl class  
> in the checkPortletAccess() method. This however, causes the portlet  
> to be visible or not visible while adding it to the page. Once the  
> portlet is added to the page, control no longer comes to this  
> method. Which means that access to the portlet cannot be turned off  
> in openSSO.
> I have a feeling that I am barking up the wrong tree here. Could  
> anyone point me in the right direction to look?
Hi Deepal  [sorry for the late response, was on vacation...]

Yes, the SecurityAccessControl is a nice abstraction over the various  
kinds of authorization methods available in Jetspeed. Unfortunately I  
have not completely abstracted all authorization checks. The checks to  
see if a page can be rendered or not is done in the aggregation  
engine. However, if you look at the PortletRenderImpl.java, you will  
see that it does indeed use the Security Access Controller to check to  
see if a portlet can be rendered:

     protected boolean  
checkSecurityConstraint(PortletDefinitionComposite portlet,  
ContentFragment fragment)
         if (fragment.getType().equals(ContentFragment.PORTLET))
             if (accessController != null)
                 return accessController.checkPortletAccess(portlet,  
         return true;

Another problem I see here, is the portlet definition security is  
checked but I don't see where the fragment is checked ... so I believe  
that might actually get filtered out in the page manager.

     public void checkAccess(String actions) throws SecurityException
         // check access permissions and constraints as enabled
         if (getPermissionsEnabled())
             int mask = pf.parseActions(actions);
         if (getConstraintsEnabled())

which does not use the Security Access Control arbitration ... making  
it harder for you to place your authorization overrides ...

Also, there is the matter of the actions on the portlet window that  
represent portlet modes....

To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org

To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org

View raw message