Jetspeed Proposal: role-based authorization concept
LAST MODIFIED: $Date: 2000/08/21 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.
*
****************************************************************************
****
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.
As a result we can define which role should be able to access which
portlets.
Also we can define which portlet-buttons (edit, maximize) should be
available
to which role. This extends the current concept to enable the edit button
just
for all authenticated users.
The following proposal describes a way to enable a role-based authorization.
Follow ups:
- JetSpeed specific role concept with administration UI
- role-specific default PSML definitions
****************************************************************************
****
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. For
this
cases we can add a special workaround, which is described in the next
section, to
make the life of the administrator easier.
****************************************************************************
****
2. Storage of authorization information
****************************************************************************
****
We should not store the authorization information inside of the user
management,
because we need to have a clear separation to JetSpeed. That separation
enables
us to exchange the user management very easily. So we must store the
authorization
information inside of JetSpeed.
Actually we should go the same way as before and store them inside of XML
configuration files. Because of the close relation between the portlet and
its
role dependent restrictions we should store these information inside of the
portlet registry:
<registry>
...
<portlet ...>
...
<security>
<access mode="view">
<all/>
</access>
<access mode="maximize">
<all/>
</access>
<access mode="edit">
<role>seller</role>
<role>buyer</role>
</access>
</security>
...
</portlet>
...
</registry>
With the <access> tags we can describe access permissions to all generic
portlet
functions.
As described above we will have the default, which a role is not allowed to
access
a portlet. So we have to define roles, which have access. Of course we will
have
a lot of portlets, which can be accessed freely by anybody - we don't need
restrictions here. To avoid listing all existing roles (to give them access)
we
should use the <all/> tag. This tag shows, that there is no restriction to
this
functionality. Additionaly each operator can use the inheritance mechanism
to reuse properties between a portlet and its childs.
****************************************************************************
****
3. API to access this information
****************************************************************************
****
To allow other parts of JetSpeed to retrieve this information we should add
new methods to the portlet's API:
public boolean accessAllowed(Role theRole, String mode);
public RoleSet allowedRoles(String mode);
Both methods need the input parameter 'mode' to know, which access
permissions
are requested (view, edit, maximize, ...)
****************************************************************************
****
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>
****************************************************************************
****
5. 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]
