SCHAECK
Thu, 22 Feb 2001 10:48:42 -0800
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]