I'm planning to implement a fine-grained security mechanism within Jetspeed that should roughly look like this:
- There's one portal-admin that has access to all functionality (just like the existing admin) - The portal-admin creates new users and can hand down some (or all) of his privileges to them. - Users who have the privilege to create new users can repeat this process, i.e. hand down their privileges to created users.
The first problem I encountered was the existing distinction in Jetspeed between ordinary and administrative portlets. I wanted to allow a user of a role other than 'admin' to create new users, so I created a new role and a constraint giving full access for that role. Then I assigned that constraint to the 'UserBrowser' portlet. Users with the new role do not see the portlet in the list of available portlets, though. Is that because the portlet is part of the package "portlets.security"? It works when I add the portlet to the user's psml file manually, but I don't like to do that.
I'm hoping I can implement the above system using the existing Permission-/Role-/GroupManagement interfaces. Has anyone had experience with similar issues?
Also, I don't know how to use the 'groups' feature of Jetspeed. The mail archives didn't really help with understanding. I have learned that you can add users to groups using the jetspeed.services.security. GroupManagement interface, and that you can assign portlets to groups using tags such as <category group=Jetspeed> in the registry. I would expect that portlets of group X can only be viewed by users of group X?
That's not the case, though. Someone posted that groups are just a way of grouping portlet resources, not users. But why, then, can I add users to groups by means of the GroupManagement interface? I'm puzzled.
T�m
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
