"Schwarz, Marcus" <[EMAIL PROTECTED]> wrote:
>Jetspeed Proposal: role-based authorization concept
>LAST MODIFIED: 2000/08/21 01:00:21
>AUTHOR: [EMAIL PROTECTED]
>STATUS: pending
[SNIPPED]
>The initial idea of this proposal is to integrate an authorization
>mechanism into JetSpeed. Currently it is not possible to restrict
>the access to a portlet or parts of its functionality (for example
>the edit-button) to some users/roles.
>
>Especially if we want to use JetSpeed inside of a company this is an
>absolute must! Just think about a portlet, which can show the salary
>of each employee. In this case we must have the ability to restrict
>the usage to people of the HR department.
>On the other hand it is not necessary to enable this restriction
>mechanism on the user level. In general we would restrict the access
>to a group of users (for example the members of the HR department).
>These users will be members of a specific role. As a result we should
>enable access to portlet functionality depending on their roles.
Username may still need to be used in the access/denial specfication.
Otherwise, how do you deny access to one user of the HR group, but allow
access to all others? I think something like below could be used:
<registry>
...
<portlet ...>
...
<security>
<access mode="view">
<allow>
<role>a role
<permission>a role permission</permission>
<permission>another permission</permission>
</role>
<user>a username</user>
</allow>
<deny>
<role>a role</role>
<user>a username</user>
</deny>
</access>
</security>
...
</portlet>
...
</registry>
Username is just matched against the user attempting access. Since
permissions are not specified in the deny/role part, they are not used. Any
user in the role specified would be denied. But in allow, any user in the
given role, that has one of the given permissions, will have access. I think
we need to have the <deny></deny> portion to allow for more fine-grained
control of access.
[SNIPPED]
>****
>1. Default permission concept
>****
[SNIPPED]
They default of denial makes sense, but we still need a way to deny from the
group of users that are allowed as in the above case where there is one user
of the HR group we don't want to allow access.
[SNIPPED]
>***
>4. Roles inside of JetSpeed
>***
>In some scenarios we will not be able to use just the user
>management to provide the roles. In example in our case each
>application (and JetSpeed is "just" an application) will have
>it's own role and permission concept. Each application
>can push this information (maybe using the below structure) to
>the user management. There the user administrator can group these
>application roles to user roles (which are including one or
>several app roles). In this case we need the roles inside of JetSpeed.
>Another advantage is, that we would have no dependencies to the user
>management. And of course it's not possible to move the whole
>permission concept to the user management. At least the area, where
>one can define the position and visibility of portlets, must be in
>JetSpeed to ensure it's independencies. As a result we must also be
>able to store JetSpeed roles there.
>For such purposes we need a list of all in JetSpeed existing roles. In
>example if we want to show a list of all existing roles in the customisation
>UI for the administrator.
>I would suggest a simple XML-based file:
>
><roles>
> <role>
> <name>[name_of_the_role]</name>
> <description>[description_of_the_role]</description>
> </role>
> ...
></roles>
All this information ( user/role/permission ) is already in turbine,
abstracted, and working. Why not use this? We should still build the
administration ui's for jetspeed as you indicate, but the storage of all the
role information is already done. As in my example above, you can define,
down the a specific role's permission, access or denial. I have implemented
this ( via castor ) for a security portlet we use. I haven't had time to
prepare it for the list, but I was planning on submitting it for proposal.
The other parts of the propsal are 'right on', imo.
jb
Jeff Brekke
mailto:[EMAIL PROTECTED]
http://sites.netscape.net/ekkerbj
____________________________________________________________________
Get your own FREE, personal Netscape WebMail account today at
http://home.netscape.com/webmail
--
--------------------------------------------------------------
Please read the FAQ! <http://java.apache.org/faq/>
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/main/mail.html>
Problems?: [EMAIL PROTECTED]
