Re: Portlet security

[Santiago Gala]

[EMAIL PROTECTED] wrote:

> 
> 
> Santiago,
> 
> I agree that it is possible to implement the PortletAccessControl interface
> based on JAAS, JAAS provides the Subject.doAs() method that allows to
> execute code under the identity of a particular user (I know the details of
> how to do this). There are cases and environments where it is more
> advantageous to use an authorization mechanism other than JAAS.
> 

I agree. And JAAS is not available in jdk1.2. But in some cases it can be the
simplest way to get authorization (if the Application Server uses it).

> The PortletAccessControl interface does not mean to reinvent things, it is
> just to provide an abstraction of what the PortletInvoker needs (decision
> whether a given user may perform a given action on a given portlet
> instance) and allows pluggable implementations to meet this need.
> 

My concern was that the discussion looked like the whole Java security
framework was going to be ignored.
I agree that we will need to write those abstractions.I just felt concerned
about compatibility. Specially since we are running on top of a servlet
container, and we do not have full control of the VM.

> +---------+---------+---------+   +---------+
> | Portlet | Portlet | Portlet |...| Portlet |  +----------------+
> +---------+---------+---------+---+---------+  | Portlet Access |
> |               Portlet Invoker             |->| Control I/F    |
> +-------------+---------------+-------------+  +----------------+
> | Aggregation | Customization | Other Views |          |
> +-------------+---------------+-------------+          v
>                                          No-op +----------------+
>                                       Custom  +| Access Control |
>                                    J2EE/JAAS +||    Provider    |
>                                              ||+----------------+
>                                              |+----------------+
>                                              +----------------+
> 
> The AccessControlProvider implementations can map the simple
> checkPermission(user, action, portletInstanceID) call to JAAS/J2EE calls or
> to other authorization mechanisms.
> 
> In a J2EE/JAAS provider, of course all the J2EE/JAAS functionality can be
> used as you say.
> 

My whole point was to try to keep these interfaces as close as possible to 
java.security,
to avoid problems in the future. Specially when the abstractions are quite similar.

> For service projects, it should be possible to write custom
> AccessControlProviders implementing the PortletAccessInterface which might
> for example do database querys against the customer's policy databases;
> that was the main reason to define the PortletAccessControl I/F.
> 
> Probably, there also should be a no-op implementation of the
> PortletAccessControl interface that has a checkPermission method that
> always returns true to avoid imposing the JAAS access control runtime and
> configuration overhead on portals that only have public content.
> 

a NullPortletAcessController will be a very good thing for some implementations.

Also, a Controller that runs on top of whatever servlet engine authentication, using 
just
request.getUserPrincipal()
request.isUserInRole(),
plus configuration info (container and Jetspeed), looks like a reasonable alternative.

J2EE/JAAS will be needed for some other implementations.

I repeat that I was feeling concerned because nobody had expressed that we would look 
at the
java/javax. apis, not that I think that we should do everything just with them.

Regards,
        Santiago



--
--------------------------------------------------------------
To subscribe:        [EMAIL PROTECTED]
To unsubscribe:      [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/jetspeed@list.working-dogs.com/>
List Help?:          [EMAIL PROTECTED]