"Schwarz, Marcus" wrote:
>
> 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.
<snip>
> <registry>
> ...
> <portlet ...>
> ...
> <security>
> <access mode="view">
> <all/>
> </access>
> <access mode="maximize">
> <all/>
> </access>
Hm... I don't think I like the <all/>. An element is date is bad :(.
I would rather have a boolean attribute... everyone="true"
> <access mode="edit">
> <role>seller</role>
> <role>buyer</role>
> </access>
IMO. There is a problem here. role doesn't specify allow|deny. I
would propose the following:
<access operation="edit">
<role mode="access">seller</role>
</access>
> </security>
> ...
> </portlet>
> ...
> </registry>
>
<snip>
> ****************************************************************************
> ****
> 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, ...)
-1. This should be in org.apache.jetspeed.registry.peer.PortletEntry:
/**
Return all access information for this PortletEntry
*/
public Access[] getAccess();
public Access {
public boolean allowsEveryone();
public Role[] getRole();
}
... of course all the above would be dependent on the Turbine role
information and not our own classes. I just didn't lookup the correct
classname.
Also. PortletFactory should check this stuff and throw a
SecurityException
> ****************************************************************************
> ****
> 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>
huh? I am -1 on this. I would assume this meant putting users within
the jetspeed-config? This should stay within Turbine.
> ****************************************************************************
> ****
> 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....
>
+1 on this.
--
** Should SUN Open Source Java? Please Vote:
http://relativity.yi.org/java **
Kevin A Burton (e-mail: [EMAIL PROTECTED], UIN: 73488596, ZKey:
burtonator)
http://relativity.yi.org
Message to SUN Microsystems: "Please Open Source Java!"
To fight and conquer in all your battles is not supreme excellence;
supreme
excellence consists in breaking the enemy's resistance without fighting.
- Sun Tzu, 300 B.C.
--
--------------------------------------------------------------
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]
