Hardening j2-admin security by enabling render-time enforcement of security
constraints defined on portlet level and restricting access to hot deployment
and portlet metadata features to admin role only
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Key: JS2-1262
URL: https://issues.apache.org/jira/browse/JS2-1262
Project: Jetspeed 2
Issue Type: Improvement
Components: Security
Affects Versions: 2.2.1
Reporter: Ate Douma
Assignee: Ate Douma
Fix For: 2.2.2
Jetspeed currently enforces security constraints defined on portlet
(descriptor) level only for adding new portlets to a page fragment.
These portlet level constraints are by default not enforced for already
existing portlet fragments, only the security constraints on the fragment
itself.
This however makes it difficult (up to impossible) to completely 'lock down'
for instance access to certain administrative portlets to users with admin role
only if such a portlet already has been setup for a fragment with lesser strict
security constraints.
And good example for this is the PortletApplicationManager. This is typically a
portlet which only a user with admin role should be allowed to use (and see).
Restricting such access can easily be done by defining a admin-only security
constraint on the fragment containing this portlet.
However, if another user, with for instance (only) a manager role has (and
needs) access to the PortalSiteManager portlet, this might pose a potential
security issue.
The manager user then can modify the security constraint of the
PortletApplicationManager fragment to relax it again, and also allow access for
users with manager role.
The only proper way to truly lock down access to the PortletApplicationManager
portlet then is through a portlet level security constraint, as can be defined
in jetspeed-portlet.xml with a js:security-constraint-ref tag, see:
http://portals.apache.org/jetspeed-2/deployguide/guide-registry.html
However, as described above this is currently not enforced by default, e.g. as
a render-time check, only while adding new portlets to a page.
Switching this default is a trivial change, as also described in the registry
guide, through the Spring assembly configuration for the PortletRenderer.
However, when we do this, by default, the behavior and logic for the (primarily
j2-admin) portlets does change (flip) as well.
As default Jetspeed only comes with security constraints configuration for
j2-admin portlets, this change requires updating and adjusting the j2-admin
jetspeed-portlet.xml accordingly.
This will require the following changes:
- enable render-time security constraints enforcement in the PortletRenderer
configuration
- change the default application level j2-admin security constraint from
<js:security-constraint-ref>admin</js:security-constraint-ref> to
<js:security-constraint-ref>AEUV</js:security-constraint-ref>
This will retain the default behavior as with without render-time security
constraints enforcement, e.g. any user may see already pre-instantiated
j2-admin portlets, as long as they have the appropriate access for the
containing fragment (or page).
- add new/additional PortletSelector <js:metadata
name="selector.conditional.role">admin</js:metadata> constraints to j2-admin
jetspeed-portlet.xml to retain the restricted set of portlets which can be
added to a page as before
Previously j2-admin portlets were by default restricted from adding to a page
to users with admin role only, but with the new j2-admin application level
<js:security-constraint-ref>AEUV</js:security-constraint-ref> this longer is
the case.
So, every portlet which should not be allowed to be added by anyone other than
admin users now needs to be explicitly restricted with <js:metadata
name="selector.conditional.role">admin</js:metadata>
The above changes then will result in effectively the same *default* behavior
as before.
But it now also allows to further restrict global render-time access to
selected portlets where needed.
The primarily goal of these changes is to limit hot deployment and portlet
application meta data to admin users only.
For hot deployment, this means locking down access to the Portlet Application
Manager portlet (PAM), the Remote Portlet Application Deployer (RPAD) and the
PortletCloneManager portlet.
And to ensure non-admin users won't be able to 'break' this down, the same is
also required for the Permissions, Constraints and Import/Export admin portlets.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
