We also have plans in this direction, I think we should agree on a common
interface for what we do.
Some first thoughts on this topic ...
I think there are actually two points where access control must be applied:
- Customization - users should only be offered portlets that they are
allowed to use
- Access to portlets - before displaying a portlet or allowing to perform
an action on it, the portal needs to check whether the user still has
access rights
In either case, the access decision should be obtained via the same
interface.
The latter is required to cover the case that a user has selected a portlet
some time ago, when he was allowed to use it but meanwhile an administrator
has revoked his access rights.
Putting the info in the jetspeed.jcfg file is one option. Other options are
putting this info in a database or in some kind of authoritzation engine ,
e.g. Policy Director or Siteminder.
To accommodate usage of either store, JetSpeed should define an interface
to check permissions, i.e. a call like
checkPermission(user, portletID, action) or
checkPermission(group, portletID, action)
"action" may be something like display, edit, config, ...
There should be pluggable services implementing this interface, e.g. one
using settings in jetspeed.jcfg, one using a database, one using an
authorization engine, etc. One option to implement the pluggable services
would be Turine Services, i.e. we would have Turbine Authorization Services
that would be invoked through the JetSpeed Authorization Interface.
Best regards,
Thomas
Thomas Schaeck
Portal Architect
IBM Pervasive Computing Division
Phone: +49-(0)7031-16-3479 Mobile: +49-(0)171-6928407 e-mail:
[EMAIL PROTECTED] Fax: +49-(0)7031-16-4888
Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032
Boeblingen, Germany
The GlueCode team is preparing to pursue portlet-level security for
Jetspeed -- that is, the ability to make portlets visible to only
certain users. Of course, we want to build this on the existing Turbine
group/role/permission scheme.
Our initial thought is that adding attributes in jetspeed-config.jcfg of
roughly this form
<viewable-by group="foo" role="bar" perm="baz" />
would be a good way to encode the permissions. In the absence of any
such attributes, the default would be viewable by all.
A reasonable "choke point" at which to limit access to portlets would
appear to be PortletConfig.getPortletSet(). The set returned could be
filtered to remove portlets for which the user does not have permission.
This would suffice to control access both to portlets on the portal
page, and listing of portlets on the customization page (which we're
working to extend, by the way).
Thoughts on this approach, please?
--
Craig Berry - (310) 570-4140
VP Technology
GlueCode
1452 Second St
Santa Monica CA 90401
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/jetspeed@list.working-dogs.com/>
List Help?: [EMAIL PROTECTED]
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/jetspeed@list.working-dogs.com/>
List Help?: [EMAIL PROTECTED]
