You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-user@portals.apache.org by "M. Greenleaf" <mg...@avenue100.com> on 2010/01/21 13:49:58 UTC
Roles at Portlet Level and LDAP
I¹ve currently have jetspeed 2.2.0 talking to my Fedora Directory Server. I
can authenticate against it. I¹ve also defined a set of roles in LDAP that
once associated to a portlet will allow/not allow our users to access that
portlet. For example, portal users that are only allowed to review reports
will not have access to any other portlet than reports.
My next step is to associate these roles to individual portlets. I¹ve used
the Administration Role Management portlet to define the new roles, but I
have not been able to determine how to associate the new roles to our
portlet. How is this done?
Thank you in advance.
-Michelle
Re: Roles at Portlet Level and LDAP
Posted by Frank Otto <ot...@delta-barth.de>.
Hi Ate,
that works fine. Thanks for your very good explanation.
One question. How can I change the message "Access denied."? In
PortalMessages I can't find this.
kind regards,
Frank
Ate Douma schrieb:
> On 01/21/2010 01:49 PM, M. Greenleaf wrote:
>> I¹ve currently have jetspeed 2.2.0 talking to my Fedora Directory
>> Server. I
>> can authenticate against it. I¹ve also defined a set of roles in
>> LDAP that
>> once associated to a portlet will allow/not allow our users to access
>> that
>> portlet. For example, portal users that are only allowed to review
>> reports
>> will not have access to any other portlet than reports.
>>
>> My next step is to associate these roles to individual portlets. I¹ve
>> used
>> the Administration Role Management portlet to define the new roles, but I
>> have not been able to determine how to associate the new roles to our
>> portlet. How is this done?
>
> Hi Michelle,
>
> I have first a documentation link describing Jetspeed Security
> Constraints you might want to read:
>
>
> http://portals.apache.org/jetspeed-2/deployguide/guide-security-declarative-psml.html
>
>
> To restrict access to and usage of certain portlets by role, you'll have
> to setup corresponding security-contraints-def definitions in your
> page.security configuration (located in the root of the PSML pages folder).
> You can do that either by hand or using the j2-admin Security
> Constraints portlet (I suggest doing by hand first and only if need be
> tweak the configurations through the portlet).
>
> For example a "reporting" security-contraint-def, allowing only
> "view,edit" access to users with roles "reporting" or "admin" could look
> like this:
>
> <security-constraints-def name="reporting">
> <security-constraint>
> <roles>admin,reporting</roles>
> <permissions>view, edit</permissions>
> </security-constraint>
> </security-constraints-def>
>
> Then, you'll have to associate this security-contraint-def with your
> reporting portlets.
> You can do this declaratively at deployment time by bundling a
> jetspeed-portlet.xml descriptor (side-by-side the portlet.xml).
> For a minimal explanation of the jetspeed deployment descriptor, see:
> http://portals.apache.org/jetspeed-2/deployguide/guide-registry.html.
>
> A minimal jetspeed-portlet.xml associating a ReportingPortlet with the
> above "reporting" security-constraint-def could look like this:
>
> <portlet-app id="reporting-pa" version="1.0"
> xmlns="http://portals.apache.org/jetspeed"
> xmlns:js="http://portals.apache.org/jetspeed"
> xmlns:dc="http://www.purl.org/dc"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://portals.apache.org/jetspeed
> http://portals.apache.org/jetspeed-2/2.1/schemas/jetspeed-portlet.xsd">
>
> <portlet>
> <portlet-name>ReportingPortlet</portlet-name>
> <js:security-constraint-ref>reporting</js:security-constraint-ref>
> </portlet>
> ...
> </portlet-app>
>
> For a concrete example of a jetspeed-portlet.xml, look at the
> j2-admin/WEB-INF/jetspeed-portlet.xml
>
> You can also do this at runtime through the j2-admin Portlet Application
> Manager:
> - select your portlet application (reporting-pa) and portlet
> (ReportingPortlet) in the Registry Applications List portlet
> - select the security tab in the PortletDetailsManager portlet
> - select the Security Contstraint: "reporting" from the drop down list
> and save (button behind the drop down list)
> Note: this runtime only configuration will be "lost" and needs to be
> configured again if you do a redeployment of your portlet application!
>
> With the above setup, users not in role "admin" or "reporting" won't be
> able to select (see) the portlet for adding to a page anymore.
>
> However, if such a portlet already has been configured on a page
> (accessible by the user), by default it will still show up (although
> only for view mode)!
>
> To further restrict accessing already configured portlets on a page
> there are two levels you can do this:
> a) by restricting the portlet PSML page fragment with the
> security-constraint-def (or a custom, inline, security constraint)
> b) by enforcing security contraints checking at render time (disabled by
> default!)
>
> The first level, PSML fragment constraints can both be configured by
> hand in the PMSL (described on the guide I mentioned above), or at
> runtime using the portlet "configure" mode (available to users having
> "configure" permission, e.g. role admin, see predefined global "admin"
> security-constraint-ref).
>
> If you want to do this by hand your fragment definition can look like this:
>
> <fragment type="portlet" name="reporting-pa::ReportingPortlet">
> <security-constraints>
> <security-constraints-ref>reporting</security-constraints-ref>
> </security-constraints>
> </fragment>
>
> Or, you can even "inline" a security constraint configuration:
>
> <fragment type="portlet" name="reporting-pa::ReportingPortlet">
> <security-constraints>
> <security-constraint>
> <roles>admin,reporting</roles>
> <permissions>view, edit</permissions>
> </security-constraint>
> </security-constraints>
> </fragment>
>
> If you want to do this at runtime, select the "configure" mode from the
> portlet action icons (as said: requires "configure" permission). You can
> then either select one of the predefined security contraints from the
> drop down list or add a new inline constraint but currently only "view"
> permission is supported.
> (Note: in the Jetspeed 2.2.1-SNAPSHOT trunk the runtime "configure" mode
> currently is broken, we'll look into fixing that ASAP).
>
> Once you have setup the security contraints for the fragment, this
> portlet fragment will no longer show up for users without admin or
> reporting role. Logically, this fragment won't even "exist" in the page
> at runtime for the current user so won't even tried to be rendered (see
> below).
>
> Finally, as a last resort/catch-all handling, you can also enforce
> security constraints checking at render time.
> If enabled (default: false), a portlet which is not accessible to be
> viewed by the user, regardless the current page or fragment, will not be
> rendered and an "Access Denied" error message will be rendered instead.
> To enable this feature, you'll have to change a Spring configuration
> setting in WEB-INF/assembly/aggregation.xml.
> Find bean with id="org.apache.jetspeed.aggregator.PortletRenderer" and
> change the 4th constructor-arg element from false -> true
> (see also inline comment in the bean definition)
>
> <!-- Portlet Renderer -->
> <bean id="org.apache.jetspeed.aggregator.PortletRenderer"
> class="org.apache.jetspeed.aggregator.impl.PortletRendererImpl"
> init-method="start" destroy-method="stop">
> <meta key="j2:cat" value="default" />
> <constructor-arg>
> <ref bean="org.apache.pluto.PortletContainer" />
> </constructor-arg>
> <constructor-arg>
> <ref bean="org.apache.jetspeed.aggregator.WorkerMonitor" />
> </constructor-arg>
> <constructor-arg>
> <ref bean="PortalStatistics" />
> </constructor-arg>
> <constructor-arg>
> <ref bean="org.apache.jetspeed.aggregator.PortletTrackingManager" />
> </constructor-arg>
> <!-- flag indicating whether to check jetspeed-portlet.xml security
> constraints
> before rendering a portlet. If security check fails, do not
> display portlet content
> -->
> <constructor-arg type="boolean">
> <value>true</value>
> </constructor-arg>
> <constructor-arg>
> <ref bean="org.apache.jetspeed.security.SecurityAccessController" />
> </constructor-arg>
> <constructor-arg>
> <ref bean="portletContentCache" />
> </constructor-arg>
> </bean>
>
>
> HTH,
>
> Ate
>
>>
>> Thank you in advance.
>>
>> -Michelle
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: Roles at Portlet Level and LDAP
Posted by Ate Douma <at...@douma.nu>.
On 01/21/2010 01:49 PM, M. Greenleaf wrote:
> I¹ve currently have jetspeed 2.2.0 talking to my Fedora Directory Server. I
> can authenticate against it. I¹ve also defined a set of roles in LDAP that
> once associated to a portlet will allow/not allow our users to access that
> portlet. For example, portal users that are only allowed to review reports
> will not have access to any other portlet than reports.
>
> My next step is to associate these roles to individual portlets. I¹ve used
> the Administration Role Management portlet to define the new roles, but I
> have not been able to determine how to associate the new roles to our
> portlet. How is this done?
Hi Michelle,
I have first a documentation link describing Jetspeed Security Constraints you might want to read:
http://portals.apache.org/jetspeed-2/deployguide/guide-security-declarative-psml.html
To restrict access to and usage of certain portlets by role, you'll have to setup corresponding security-contraints-def definitions in your
page.security configuration (located in the root of the PSML pages folder).
You can do that either by hand or using the j2-admin Security Constraints portlet (I suggest doing by hand first and only if need be tweak
the configurations through the portlet).
For example a "reporting" security-contraint-def, allowing only "view,edit" access to users with roles "reporting" or "admin" could look
like this:
<security-constraints-def name="reporting">
<security-constraint>
<roles>admin,reporting</roles>
<permissions>view, edit</permissions>
</security-constraint>
</security-constraints-def>
Then, you'll have to associate this security-contraint-def with your reporting portlets.
You can do this declaratively at deployment time by bundling a jetspeed-portlet.xml descriptor (side-by-side the portlet.xml).
For a minimal explanation of the jetspeed deployment descriptor, see: http://portals.apache.org/jetspeed-2/deployguide/guide-registry.html.
A minimal jetspeed-portlet.xml associating a ReportingPortlet with the above "reporting" security-constraint-def could look like this:
<portlet-app id="reporting-pa" version="1.0"
xmlns="http://portals.apache.org/jetspeed"
xmlns:js="http://portals.apache.org/jetspeed"
xmlns:dc="http://www.purl.org/dc"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://portals.apache.org/jetspeed http://portals.apache.org/jetspeed-2/2.1/schemas/jetspeed-portlet.xsd">
<portlet>
<portlet-name>ReportingPortlet</portlet-name>
<js:security-constraint-ref>reporting</js:security-constraint-ref>
</portlet>
...
</portlet-app>
For a concrete example of a jetspeed-portlet.xml, look at the j2-admin/WEB-INF/jetspeed-portlet.xml
You can also do this at runtime through the j2-admin Portlet Application Manager:
- select your portlet application (reporting-pa) and portlet (ReportingPortlet) in the Registry Applications List portlet
- select the security tab in the PortletDetailsManager portlet
- select the Security Contstraint: "reporting" from the drop down list and save (button behind the drop down list)
Note: this runtime only configuration will be "lost" and needs to be configured again if you do a redeployment of your portlet application!
With the above setup, users not in role "admin" or "reporting" won't be able to select (see) the portlet for adding to a page anymore.
However, if such a portlet already has been configured on a page (accessible by the user), by default it will still show up (although only
for view mode)!
To further restrict accessing already configured portlets on a page there are two levels you can do this:
a) by restricting the portlet PSML page fragment with the security-constraint-def (or a custom, inline, security constraint)
b) by enforcing security contraints checking at render time (disabled by default!)
The first level, PSML fragment constraints can both be configured by hand in the PMSL (described on the guide I mentioned above), or at
runtime using the portlet "configure" mode (available to users having "configure" permission, e.g. role admin, see predefined global "admin"
security-constraint-ref).
If you want to do this by hand your fragment definition can look like this:
<fragment type="portlet" name="reporting-pa::ReportingPortlet">
<security-constraints>
<security-constraints-ref>reporting</security-constraints-ref>
</security-constraints>
</fragment>
Or, you can even "inline" a security constraint configuration:
<fragment type="portlet" name="reporting-pa::ReportingPortlet">
<security-constraints>
<security-constraint>
<roles>admin,reporting</roles>
<permissions>view, edit</permissions>
</security-constraint>
</security-constraints>
</fragment>
If you want to do this at runtime, select the "configure" mode from the portlet action icons (as said: requires "configure" permission). You
can then either select one of the predefined security contraints from the drop down list or add a new inline constraint but currently only
"view" permission is supported.
(Note: in the Jetspeed 2.2.1-SNAPSHOT trunk the runtime "configure" mode currently is broken, we'll look into fixing that ASAP).
Once you have setup the security contraints for the fragment, this portlet fragment will no longer show up for users without admin or
reporting role. Logically, this fragment won't even "exist" in the page at runtime for the current user so won't even tried to be rendered
(see below).
Finally, as a last resort/catch-all handling, you can also enforce security constraints checking at render time.
If enabled (default: false), a portlet which is not accessible to be viewed by the user, regardless the current page or fragment, will not
be rendered and an "Access Denied" error message will be rendered instead.
To enable this feature, you'll have to change a Spring configuration setting in WEB-INF/assembly/aggregation.xml.
Find bean with id="org.apache.jetspeed.aggregator.PortletRenderer" and change the 4th constructor-arg element from false -> true
(see also inline comment in the bean definition)
<!-- Portlet Renderer -->
<bean id="org.apache.jetspeed.aggregator.PortletRenderer"
class="org.apache.jetspeed.aggregator.impl.PortletRendererImpl" init-method="start" destroy-method="stop">
<meta key="j2:cat" value="default" />
<constructor-arg>
<ref bean="org.apache.pluto.PortletContainer" />
</constructor-arg>
<constructor-arg>
<ref bean="org.apache.jetspeed.aggregator.WorkerMonitor" />
</constructor-arg>
<constructor-arg>
<ref bean="PortalStatistics" />
</constructor-arg>
<constructor-arg>
<ref bean="org.apache.jetspeed.aggregator.PortletTrackingManager" />
</constructor-arg>
<!-- flag indicating whether to check jetspeed-portlet.xml security constraints
before rendering a portlet. If security check fails, do not display portlet content
-->
<constructor-arg type="boolean">
<value>true</value>
</constructor-arg>
<constructor-arg>
<ref bean="org.apache.jetspeed.security.SecurityAccessController" />
</constructor-arg>
<constructor-arg>
<ref bean="portletContentCache" />
</constructor-arg>
</bean>
HTH,
Ate
>
> Thank you in advance.
>
> -Michelle
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org