[EMAIL PROTECTED] wrote:
>
>
> We also have plans in this direction, I think we should agree on a common
> interface for what we do.
>
> Some first thoughts on this topic ...
>
> I think there are actually two points where access control must be applied:
>
> - Customization - users should only be offered portlets that they are
> allowed to use
> - Access to portlets - before displaying a portlet or allowing to perform
> an action on it, the portal needs to check whether the user still has
> access rights
>
> In either case, the access decision should be obtained via the same
> interface.
>
> The latter is required to cover the case that a user has selected a portlet
> some time ago, when he was allowed to use it but meanwhile an administrator
> has revoked his access rights.
>
> Putting the info in the jetspeed.jcfg file is one option. Other options are
> putting this info in a database or in some kind of authoritzation engine ,
> e.g. Policy Director or Siteminder.
>
> To accommodate usage of either store, JetSpeed should define an interface
> to check permissions, i.e. a call like
>
> checkPermission(user, portletID, action) or
> checkPermission(group, portletID, action)
>
> "action" may be something like display, edit, config, ...
>
We could use java.security.Permission (in general all of the java.security.*
framework).
We could write
org.apache.jetspeed.security.DisplayPermission,
org.apache.jetspeed.security.EditPermission,
org.apache.jetspeed.security.XXXPermission,...
This should be integratable with Turbine now, and with any java enterprise
application, allowing
code like the following (in tomcat/examples/jsp/security) to be gracefully extended by
turbine/jetspeed.
---> (from tomcat examples)
You are logged in as remote user <b><%= request.getRemoteUser() %></b><br><br>
<%
if (request.getUserPrincipal() != null) {
%>
Your user principal name is <b><%= request.getUserPrincipal().getName() %></b><br><br>
<%
} else {
%>
No user principal could be identified.
<%
}
%>
(...) including roles and acl.
<----
> There should be pluggable services implementing this interface, e.g. one
> using settings in jetspeed.jcfg, one using a database, one using an
> authorization engine, etc. One option to implement the pluggable services
> would be Turine Services, i.e. we would have Turbine Authorization Services
> that would be invoked through the JetSpeed Authorization Interface.
>
All of the java.security.* framework is interface based.
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/jetspeed@list.working-dogs.com/>
List Help?: [EMAIL PROTECTED]
