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 David Sean Taylor <da...@bluesunrise.com> on 2002/10/12 06:49:59 UTC
Securing VelocityPortlet actions
I'd like to use the Jetspeed Security registry for securing access to
Velocity portlet actions.
I believe that Velocity portlet action events are very big security hole in
Jetspeed, and it should be fairly simple to plug it, one would think.
A few weeks ago I reviewed the code, and it was the same old situation: we
are in the action, but do we have access to the portlet....
To make a long story short, I failed to get access to the portlet in the
action when I needed it -- when an action event kicks off, it doesn't know
about its portlet. Correct me if Im wrong....I can just hear Raphael "its
easy, just do this..." and I hope he does, really.
But since the action kicks off before the instance is created, its even more
difficult to get the portlet instance security-ref.
Any insight on how to get the security constraints during an action event?
I would like to put this code in one of the base classes. I don't want to be
checking security in each and everyone of my action events.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Securing VelocityPortlet actions
Posted by David Sean Taylor <da...@bluesunrise.com>.
> Actually, JspPortletAction will not run any of its build* methods unless
> there's a "portlet" attribute in the request. This attribute gets
> set in the
> JspPortlet so if the action was invoked via URL, it wouldn't run. I think
> that VelocityPortlet works in similar fashion. Well, I know it
> does, because
> I modeled JspPortletAction on VelocityPortletAction. What I am missing?
If I remember, calling context.get("portlet") in an action event (doXXXX)
returns NULL.
VelocityPortlet portlet =
(VelocityPortlet)context.get("portlet");
This doesn't happen until the control builds its context
context.put("portlet", portlet );
>
> >
> > > about securing non-portlet actions? Perhaps these actions
> should become
> > > another type of portal resource and extend JetspeedAction
> > which, in turn,
> > > would be responsible for checking PERMISSION_EXECUTE.
> >
> > Yes, 'normal' turbine actions also need to be secured.
> > PERMISSION_EXECUTE, yes, that may work. I was thinking of just
> > hooking into
> > the current mode (view, customize), but yes, I like execute permission.
> > +1 on adding it
> >
>
> I guess I didn't think this through. If we use security contraint
> to secure
> a turbine action, what do we attach it to? Unless we assume that the
> security constraint is named the same as the action. How about if we use
> turbine permissions and roles? We could create a base action class which
> would check for existence of permission with the same name as the action
> class. If such permission exists that would mean the action is secured.
> Next, it would check the user permissions to see if the user can
> execute the
> action.
>
For Velocity Action events, I was thinking it would be attached to the
portlet or portlet instance constraint.
However, one could argue that each action event should have its own
constraints.
As for Turbine actions, why not create a new type of resource: action.
The PortalAccessController interface doesn't support actions
Don't confuse the 2nd parameter, its an 'action' as in permission
public interface PortalAccessController extends Service
{
// check a portlet instance for a given permission/action
public boolean checkPermission(JetspeedUser user, Entry entry, String
action, String owner);
// check a portlet for a given permission/action
public boolean checkPermission(JetspeedUser user, Portlet portlet,
String action, String owner);
// check a Portal Resource for a given permission/action
public boolean checkPermission(JetspeedUser user, PortalResource
resource, String action);
}
The third looks promising:
public class PortalResource implements Serializable
{
public static final int TYPE_PORTLET = 100;
public static final int TYPE_ENTRY = 200;
public static final int TYPE_ENTRY_PARAMETER = 201;
public static final int TYPE_REGISTRY = 300;
public static final int TYPE_REGISTRY_PARAMETER = 301;
why don't we add
public static final int TYPE_ACTION = 400;
public static final int TYPE_ACTION_EVENT = 401;
and then new constructors
public PortalResource(Action action )
public PortalResource(ActionEvent actionEvent)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Securing VelocityPortlet actions
Posted by Mark Orciuch <ma...@ngsltd.com>.
David,
> >
> > No, I don't have any insight for you yet but I'm trying to make sure I
> > understand your intent here. You want to secure portlet and its
> action as
> > one (i.e. portlet action should always use security of the portlet it is
> > associated with), right? And you don't want to do something like
> > that in the
> > base action class:
> >
> > JetspeedSecurity.checkPermission(rundata,
> > JetspeedSecurity.PERMISSION_VIEW,
> > portlet);
>
> Exactly, but I can't get to the 3rd parameter 'portlet' - it
> should be soooo
> easy but its not
>
> >
> > Whatever we come up with, has to be done with JspPortletAction as
> > well. What
>
> +1
Actually, JspPortletAction will not run any of its build* methods unless
there's a "portlet" attribute in the request. This attribute gets set in the
JspPortlet so if the action was invoked via URL, it wouldn't run. I think
that VelocityPortlet works in similar fashion. Well, I know it does, because
I modeled JspPortletAction on VelocityPortletAction. What I am missing?
>
> > about securing non-portlet actions? Perhaps these actions should become
> > another type of portal resource and extend JetspeedAction
> which, in turn,
> > would be responsible for checking PERMISSION_EXECUTE.
>
> Yes, 'normal' turbine actions also need to be secured.
> PERMISSION_EXECUTE, yes, that may work. I was thinking of just
> hooking into
> the current mode (view, customize), but yes, I like execute permission.
> +1 on adding it
>
I guess I didn't think this through. If we use security contraint to secure
a turbine action, what do we attach it to? Unless we assume that the
security constraint is named the same as the action. How about if we use
turbine permissions and roles? We could create a base action class which
would check for existence of permission with the same name as the action
class. If such permission exists that would mean the action is secured.
Next, it would check the user permissions to see if the user can execute the
action.
Best regards,
Mark C. Orciuch
Next Generation Solutions, Ltd.
e-Mail: mark_orciuch@ngsltd.com
web: http://www.ngsltd.com
> >
> >
> > > -----Original Message-----
> > > From: David Sean Taylor [mailto:david@bluesunrise.com]
> > > Sent: Friday, October 11, 2002 11:50 PM
> > > To: Jetspeed Developers List
> > > Subject: Securing VelocityPortlet actions
> > >
> > >
> > > I'd like to use the Jetspeed Security registry for securing access to
> > > Velocity portlet actions.
> > > I believe that Velocity portlet action events are very big
> > > security hole in
> > > Jetspeed, and it should be fairly simple to plug it, one would think.
> > > A few weeks ago I reviewed the code, and it was the same old
> > situation: we
> > > are in the action, but do we have access to the portlet....
> > >
> > > To make a long story short, I failed to get access to the
> portlet in the
> > > action when I needed it -- when an action event kicks off, it
> > doesn't know
> > > about its portlet. Correct me if Im wrong....I can just hear
> > Raphael "its
> > > easy, just do this..." and I hope he does, really.
> > >
> > > But since the action kicks off before the instance is created,
> > > its even more
> > > difficult to get the portlet instance security-ref.
> > >
> > > Any insight on how to get the security constraints during an
> > action event?
> > > I would like to put this code in one of the base classes. I don't
> > > want to be
> > > checking security in each and everyone of my action events.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Securing VelocityPortlet actions
Posted by David Sean Taylor <da...@bluesunrise.com>.
> -----Original Message-----
> From: Mark Orciuch [mailto:mark_orciuch@ngsltd.com]
> Sent: Monday, October 14, 2002 8:49 AM
> To: Jetspeed Developers List
> Subject: RE: Securing VelocityPortlet actions
>
>
> David,
>
> No, I don't have any insight for you yet but I'm trying to make sure I
> understand your intent here. You want to secure portlet and its action as
> one (i.e. portlet action should always use security of the portlet it is
> associated with), right? And you don't want to do something like
> that in the
> base action class:
>
> JetspeedSecurity.checkPermission(rundata,
> JetspeedSecurity.PERMISSION_VIEW,
> portlet);
Exactly, but I can't get to the 3rd parameter 'portlet' - it should be soooo
easy but its not
>
> Whatever we come up with, has to be done with JspPortletAction as
> well. What
+1
> about securing non-portlet actions? Perhaps these actions should become
> another type of portal resource and extend JetspeedAction which, in turn,
> would be responsible for checking PERMISSION_EXECUTE.
Yes, 'normal' turbine actions also need to be secured.
PERMISSION_EXECUTE, yes, that may work. I was thinking of just hooking into
the current mode (view, customize), but yes, I like execute permission.
+1 on adding it
>
> Best regards,
>
> Mark C. Orciuch
> Next Generation Solutions, Ltd.
> e-Mail: mark_orciuch@ngsltd.com
> web: http://www.ngsltd.com
>
>
> > -----Original Message-----
> > From: David Sean Taylor [mailto:david@bluesunrise.com]
> > Sent: Friday, October 11, 2002 11:50 PM
> > To: Jetspeed Developers List
> > Subject: Securing VelocityPortlet actions
> >
> >
> > I'd like to use the Jetspeed Security registry for securing access to
> > Velocity portlet actions.
> > I believe that Velocity portlet action events are very big
> > security hole in
> > Jetspeed, and it should be fairly simple to plug it, one would think.
> > A few weeks ago I reviewed the code, and it was the same old
> situation: we
> > are in the action, but do we have access to the portlet....
> >
> > To make a long story short, I failed to get access to the portlet in the
> > action when I needed it -- when an action event kicks off, it
> doesn't know
> > about its portlet. Correct me if Im wrong....I can just hear
> Raphael "its
> > easy, just do this..." and I hope he does, really.
> >
> > But since the action kicks off before the instance is created,
> > its even more
> > difficult to get the portlet instance security-ref.
> >
> > Any insight on how to get the security constraints during an
> action event?
> > I would like to put this code in one of the base classes. I don't
> > want to be
> > checking security in each and everyone of my action events.
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Securing VelocityPortlet actions
Posted by Mark Orciuch <ma...@ngsltd.com>.
David,
No, I don't have any insight for you yet but I'm trying to make sure I
understand your intent here. You want to secure portlet and its action as
one (i.e. portlet action should always use security of the portlet it is
associated with), right? And you don't want to do something like that in the
base action class:
JetspeedSecurity.checkPermission(rundata, JetspeedSecurity.PERMISSION_VIEW,
portlet);
Whatever we come up with, has to be done with JspPortletAction as well. What
about securing non-portlet actions? Perhaps these actions should become
another type of portal resource and extend JetspeedAction which, in turn,
would be responsible for checking PERMISSION_EXECUTE.
Best regards,
Mark C. Orciuch
Next Generation Solutions, Ltd.
e-Mail: mark_orciuch@ngsltd.com
web: http://www.ngsltd.com
> -----Original Message-----
> From: David Sean Taylor [mailto:david@bluesunrise.com]
> Sent: Friday, October 11, 2002 11:50 PM
> To: Jetspeed Developers List
> Subject: Securing VelocityPortlet actions
>
>
> I'd like to use the Jetspeed Security registry for securing access to
> Velocity portlet actions.
> I believe that Velocity portlet action events are very big
> security hole in
> Jetspeed, and it should be fairly simple to plug it, one would think.
> A few weeks ago I reviewed the code, and it was the same old situation: we
> are in the action, but do we have access to the portlet....
>
> To make a long story short, I failed to get access to the portlet in the
> action when I needed it -- when an action event kicks off, it doesn't know
> about its portlet. Correct me if Im wrong....I can just hear Raphael "its
> easy, just do this..." and I hope he does, really.
>
> But since the action kicks off before the instance is created,
> its even more
> difficult to get the portlet instance security-ref.
>
> Any insight on how to get the security constraints during an action event?
> I would like to put this code in one of the base classes. I don't
> want to be
> checking security in each and everyone of my action events.
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>