You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by Deepak Kaimal <dk...@trestlellc.com> on 2009/07/28 17:20:03 UTC
Jetspeed Authorization
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?
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: Jetspeed Authorization
Posted by David Sean Taylor <d....@onehippo.com>.
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?
>
The SecurityAccessController delegates its security checks.
Looking at the SecurityAccessController default impl:
public boolean checkPortletAccess(PortletDefinition portlet, int
mask)
{
if (portlet == null)
return false;
if (securityMode == SecurityAccessController.CONSTRAINTS)
{
String constraintRef =
portlet.getJetspeedSecurityConstraint();
if (constraintRef == null)
{
constraintRef =
((PortletApplication
)portlet.getApplication()).getJetspeedSecurityConstraint();
if (constraintRef == null)
{
return true; // allow access
}
}
String actions = JetspeedActions.getContainerActions(mask);
return pageManager.checkConstraint(constraintRef, actions);
}
else
{
try
{
AccessController .checkPermission
((Permission
)pf.newPermission(pf.PORTLET_PERMISSION,portlet.getUniqueName(),
mask));
}
catch (AccessControlException ace)
{
return false;
}
return true;
}
}
There are two Security Authorization implementations in Jetspeed:
1. Security Constraints - authorization checks are made against
constraints associated with portal resources (pages, folders)
2. Java Security Policy - authorization checks are made against
Jetspeed's standard Java Security Policy
You can see in the code above where the SecurityAccessController
checks its configuration, and delegates to either the constraints or
policy authorization implementation.
<!--
Security Mode:
1 = Permissions = use Jetspeed Java Security Policy
2 = Constraints = use Jetspeed (PageManager) Constraint-based
Security
-->
<constructor-arg index="2">
<value>${portal.core.security.type}</value>
</constructor-arg>
So you need to look at the jetspeed.properties for the
portal.core.security.type setting:
#1 = Permissions = use Jetspeed Java Security Policy
#2 = Constraints = use Jetspeed (PageManager) Constraint-based
Securityportal.core.security.type=2
I don't recommend editing jetspeed.properties directly, but instead
using the override.properties as described here:
http://portals.apache.org/jetspeed-2/deployguide/jetspeed-properties.html
http://portals.apache.org/jetspeed-2/deployguide/override-properties.html
You can read more about constraints vs permissions here:
http://portals.apache.org/jetspeed-2/deployguide/security-config.html
Re: Jetspeed Authorization
Posted by David Sean Taylor <d....@onehippo.com>.
On Aug 20, 2009, at 7:02 PM, Deepak Kaimal wrote:
> Would you like help with this? If so, where do I start?
Start by creating a JIRA issue.... we can discuss the work there
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
RE: Jetspeed Authorization
Posted by Deepak Kaimal <dk...@trestlellc.com>.
Would you like help with this? If so, where do I start?
-----Original Message-----
From: David Sean Taylor [mailto:d.taylor@onehippo.com]
Sent: Wednesday, August 19, 2009 4:35 PM
To: Jetspeed Developers List
Subject: Re: Jetspeed Authorization
On Aug 19, 2009, at 2:15 PM, Deepak Kaimal wrote:
> 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.
>
OK... yes, we have the Java Security Policy based checks as well as
Security Constraints. I still like the idea of having a central
security accessor service as the dependency to all other services
requiring high level authorization checks. I am considering creating a
JIRA issue to complete this work, although Im quite busy right now
coming, especially after returning from vacation :) and not sure when
I can get to it
---------------------------------------------------------------------
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
Re: Jetspeed Authorization
Posted by David Sean Taylor <d....@onehippo.com>.
On Aug 19, 2009, at 2:15 PM, Deepak Kaimal wrote:
> 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.
>
OK... yes, we have the Java Security Policy based checks as well as
Security Constraints. I still like the idea of having a central
security accessor service as the dependency to all other services
requiring high level authorization checks. I am considering creating a
JIRA issue to complete this work, although Im quite busy right now
coming, especially after returning from vacation :) and not sure when
I can get to it
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
RE: Jetspeed Authorization
Posted by Deepak Kaimal <dk...@trestlellc.com>.
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: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,
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: 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
Re: Jetspeed Authorization
Posted by David Sean Taylor <d....@onehippo.com>.
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: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org