Jetspeed Proposal: role-based authorization concept
LAST MODIFIED: $Date: 2000/08/25 01:00:21 $
AUTHOR: [EMAIL PROTECTED]
STATUS: pending
****************************************************************************
****
* WARNING: THIS DOCUMENT WAS INITIALLY A PROPOSAL. PLEASE CHECK THE DATE
AS *
* THIS MAY HAVE BECOME OLD.
*
****************************************************************************
****
This proposal should not replace security stuff from Turbine. Still we will
and should use Turbine to support JetSpeed with role/permission information.
But it should enable JetSpeed to apply these security configurations to
portlets. So *still* Turbine will be the framework, which is containing the
user, role and permission information.
History: - have changed structure and some concepts in 2 (thanks to Jeff)
- changed API in 3 (thanks to Kevin)
- skipped 4 "Storage of roles inside of JetSpeed" - some
organisatins
must still do it, but should be seperated from JetSpeed using the
Turbine framework. So inclusion to standard make no sense.
****************************************************************************
****
1. Default permission concept
****************************************************************************
****
We can go two ways:
- by default each role is allowed to access all portlets. We have to define
which roles are not allowed to.
- by default nobody is allowed to access a portlet. We have to define which
role is allowed to.
In the first look approach one seems easier. But we will run in too much
security
issues. Just think about 'confidential' portlets, like the above-mentioned
salary
portlet. Because everybody would have access by default, we would need to
add all
roles to the configuration, which are not allowed to access - and these are
the
most!
Now imagine the situation that we need to add a new role: The administrator
would
have to take care that the access to all the confidential portlets would be
restricted in adding the new role to the 'deny'-list! And now imagine he/she
would
forget the salary-portlet by accident....
The example shows: the allow-everything approach is not feasible from a
security
point of view! So we have to deny access by default. Of course the most
portlets
would be allowed to be viewed by every role.
****************************************************************************
****
2. Storage of authorization information
****************************************************************************
****
The information should be stored in the registry:
<registry>
...
<portlet ...>
...
<security>
<access mode="view" everyone="true"/>
<access mode="maximize" everyone="true"/>
<access mode="edit" everyone="false">
<allow>
<role>role1
<permission>perm1</permission>
<permission>perm2</permission>
</role>
<role>role2</role>
<user>user1</user>
</allow>
<deny>
<role>role3</role>
<user>user2</user>
</deny>
</access>
</security>
...
</portlet>
...
</registry>
The access-tag is describing the access to a portlet.
With the everyone="true" attribute we can grant access permissions to all
generic
portlet functions without listing all exisiting roles/users.
In general every role/user is not allowed to access the functionality.
The allow-tag contains all roles/users allowed to access the functionality.
In
detail all users in the specific role, which are owning one of the specified
permissions, are allowed to access. If just a role without any permission is
specified any members of this role independed of the permission will have
access.
That's especially important, because some user managements don't handle
permissions just roles.
The deny-tag allows to deny access inside of these group. In example we will
allow
access to the role 'HR-department' but will exclude user 'John'. In the most
cases
it makes no sense to deny access to a role, because by default each role has
no
access. But if one is using a user management which can handle roles and
sub-roles
this tag is interesting.
The usage of the user-tag depends on the strategy of the organisation. In
some
cases it is useful to define everything with roles. Then we don't have to
exclude
a user, because this user will be a member of a different role. But JetSpeed
should
be able to handle both scenarios.
****************************************************************************
****
3. API to access this information
****************************************************************************
****
To allow other parts of JetSpeed to retrieve this information we should add
a new method to org.apache.jetspeed.registry.peer.PortletEntry:
public Access[] getAccess();
Definition of Access:
public class Access
{
public boolean allowsEveryone(String mode);
public Role[] getRole(String mode);
public boolean allowsRole(String mode);
}
Both methods need the input parameter 'mode' to know, which access operation
are requested (view, edit, maximize, ...)
****************************************************************************
****
4. Additions in administration UI
****************************************************************************
****
The new capabilities must be reflected in the administration UI. We need the
following functionality:
- Define access permissions on role-base for the portlets
We have to provide a matrix-based screens the administrator can use to
define which access-option (view, edit, maximize) of a portlet a role
should have. A button on the left hand should enable to set the above
mentioned <all/>-tag --> every role (also new roles) will have access
to this
functionality.
The screen should look similar to this:
all | Portlet | Role1 | Role2 | Role3
----------------------------------------------------
| News Feed | | |
O | - view | X | X | O
O | - edit | X | O | O
O | - maximize | X | X | O
----------------------------------------------------
| Bulletin Board | | |
X | - view | X | X | X
....
If "all" is selected automatically the whole row is selected.
If "view" for a role is disabled all the other functions (edit,
maximize) are
automatically disabled.
- Create, modify, delete JetSpeed role
Will come soon....
--
--------------------------------------------------------------
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]
