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: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
