David, 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 system. 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:[email protected]] 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, JetspeedActions.MASK_VIEW); } } 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); checkPermissions(mask); } if (getConstraintsEnabled()) { checkConstraints(actions); } } 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: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
