Is this proposal being presented in such a way as to allow authorization
from an external source such as LDAP. It is mentioned here that role-based
authorization is a necessity if Jetspeed is to be run inside a company. In
conjunction with that the mentioned API should provide a level of
abstraction as to allow the authorization source be one of many types, xml,
ldap, relational, etc.
Just my .02
Randy Bielby
Consultant
Greenbrier & Russel: The People You Trust with eBusiness
Madison, Wisconsin
www.gr.com
(608) 827-6760
[EMAIL PROTECTED]
> -----Original Message-----
> From: Schwarz, Marcus [SMTP:[EMAIL PROTECTED]]
> Sent: Monday, August 21, 2000 5:52 PM
> To: JetSpeed Mailing List (E-mail)
> Subject: PROPOSAL: role-based authorization concept
>
> 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]
--
--------------------------------------------------------------
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]
