Slide - Cocoon principal roles

[Peter Paulus <pa...@neroc.nl>]

Hello all,

We've been trying to login into Slide x.y from Cocoon 2.1. We want to use
the Slide user role information for permissions in Cocoon.

On looking at the source of
'org.apache.cocoon.components.repository.impl.SlidePrincipalProvider'
(Cocoon distribution) and 'org.apache.slide.security.SecurityImpl' (Slide
distribution), I noticed the following:

In Cocoon 'getPrincipals() is called on the configured (cocoon.xconf)
principalprovider: SlidePrincipalProvider.

SlidePrincipalProvider.getPrincipals() gets it's roles from SecurityImpl by
calling getRoles().

In getRoles() a vector of role(string)s is build as follows:

element 0: the configured string for role 'nobody'
element 1 .. m: the configured strings (Domain.xml) for the supported
interfacenames implemented by the classname of user (e.g. for user Peter
Paulus this will be in file /users/Peter Paulus.def.xml when using the file
store). If there is no configured name, the interfacename is used.
element n .. q: the same as above for all classes in the 'inheritance'-path.

So for sliderole.basic.RootRoleImpl this would be:
element 0: 'nobody'
element 1: 'root'

This Vector is passed as an Enumeration to getPrincipals(). getPrincipals()
then processes that as follows:

...
// FIXME the CVS code from slide does only implement getRoles
Enumeration roles = this.security.getRoles(userobject);
String role = null;
if (roles.hasMoreElements())
   {
   role = (String) roles.nextElement();
   }
...

the postcondition of this code is that role is either the null-object or a
String with contents 'nobody'.

I think there are a number of improvements to make:

1. I suppose the role 'nobody' is assigned to everybody. Why would you want
to make this role explicit? Having no configured roles, means having role
'nobody'.

2. There is a decrepancy in the modelling for principals between Slide and
Cocoon. In Slide a user can have 1 or more roles (?, see remarks further
on). In Cocoon a user has zero or 1 role.

So, in order to propagate one of the roles in Slide to Cocoon, we have a
(non-)deterministic problem: which role in Slide do we select to give to
Cocoon?

In my opinion that should be the 'broadest' role. But Slide doesn't have a
concept of the 'broadness' of roles. So if a user has both 'roles' user and
'guest', the role 'user' should be presented. There is no way, currently, in
Slide to do that. 'Broadness' should be a precedence relation on roles.

The best way to deal with this, in the current state of affairs, is to
present the role that is closest to the classname-attribute in the user's
.def.xml file. (similar is is done currently, see also ad 3).

remark 1:
I'm not sure whether in Slide a user can have more than 1 role. When I look
at the users .def.xml file, I can only see that the user has exactly 1 type,
which is configured by the classname attribute on the objectnode element.
One would expect a user to be configured with multiple roles

remark 2:
This type of the configured classname corresponds to a role and descends
from SubjectNode - ObjectNode. On all three classes I fail to find methods
that deal with roles.

remark 3:
In the slide admin web application only 1 role is listed/selectable.

3. The vector of roles is build by using refelection on the role
implementation class. This presents a (academic) problem.

Not knowing what I know today, I've created to new role interfaces
'PartnerRole' and 'AuthorRole' as follows.

public interface PartnerRole extends slideroles.basic.GuestRole {}
public interface AuthorRole extends slideroles.basic.UserRole {}

My 'PartnerRoleImpl' must now implement all methods of the 'PartnerRole'
interface as well as all methods of the 'GuestRole' interface. So you could
say it supports both the 'partner' and 'guest' role.

Somehow, traversing over the class hierarchy of my 'PartnerRoleImpl', I
suppect the 'guest' role is missed. I suppose you'd have to also resolve all
superclasses of the interfaces one finds.

4. Non role-related interfaces are included aswell. When the class hierarchy
is traversed, it is thinkable (again, maybe an academic point) that
interfaces are found that have nothing to do with roles whatsoever.

The PartnerRoleImpl can in fact implement loads of other interfaces.

I'm not sure whether I'd want to present those roles in a popup in a
struts/jsp page.

5. I not sure whether order of the vector is important. But if it is, and it
seems so for Cocoon, could then the order of the Class.getInterfaces() be
different on different Virtual Machines?

And suppose that every Virtual Machine maintains the order as specified in
the source file. How can one guarantee that future developers specify the
intended order?

Again this is somewhat academic.

As for the selection of the Cocoon role:
I think for now it would be save for getPrincipals() to take the second role
in getRoles() provided that your role implementation class specifies the
'broadest' role as it's first interface:

public class PartnerRoleImpl extends SubjectNode
implements PartnerRole, GuestRole
{
}

With kind regards,
Peter Paulus


---------------------------------------------------------------------
To unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-user-help@jakarta.apache.org

Re: Slide - Cocoon principal roles

[Stephan Michels <st...@apache.org>]

On Thu, 31 Jul 2003, Peter Paulus wrote:

You should know that the Slide block within Cocoon isn't finished, and
need help from third persons.

> This Vector is passed as an Enumeration to getPrincipals(). getPrincipals()
> then processes that as follows:
>
> ...
> // FIXME the CVS code from slide does only implement getRoles
> Enumeration roles = this.security.getRoles(userobject);
> String role = null;
> if (roles.hasMoreElements())
>    {
>    role = (String) roles.nextElement();
>    }
> ...
>
> the postcondition of this code is that role is either the null-object or a
> String with contents 'nobody'.
>
> I think there are a number of improvements to make:
>
> 1. I suppose the role 'nobody' is assigned to everybody. Why would you want
> to make this role explicit? Having no configured roles, means having role
> 'nobody'.
>
> 2. There is a decrepancy in the modelling for principals between Slide and
> Cocoon. In Slide a user can have 1 or more roles (?, see remarks further
> on). In Cocoon a user has zero or 1 role.

This comes from the fact that I wanted to use the authentification
framework from Carsten, which currently only one role supports.

> 5. I not sure whether order of the vector is important. But if it is, and it
> seems so for Cocoon, could then the order of the Class.getInterfaces() be
> different on different Virtual Machines?
>
> And suppose that every Virtual Machine maintains the order as specified in
> the source file. How can one guarantee that future developers specify the
> intended order?

At the moment the future of the Slide block is unclear. I have implemented
a first bridge between Slide and Cocoon, but this seems more to be a
one-man show. To keep this block alive I need support from others.

So, if you want to enhance the code base, when are patches welcome.

Stephan.

Re: Slide - Cocoon principal roles

[Stephan Michels <st...@apache.org>]

On Thu, 31 Jul 2003, Peter Paulus wrote:

You should know that the Slide block within Cocoon isn't finished, and
need help from third persons.

> This Vector is passed as an Enumeration to getPrincipals(). getPrincipals()
> then processes that as follows:
>
> ...
> // FIXME the CVS code from slide does only implement getRoles
> Enumeration roles = this.security.getRoles(userobject);
> String role = null;
> if (roles.hasMoreElements())
>    {
>    role = (String) roles.nextElement();
>    }
> ...
>
> the postcondition of this code is that role is either the null-object or a
> String with contents 'nobody'.
>
> I think there are a number of improvements to make:
>
> 1. I suppose the role 'nobody' is assigned to everybody. Why would you want
> to make this role explicit? Having no configured roles, means having role
> 'nobody'.
>
> 2. There is a decrepancy in the modelling for principals between Slide and
> Cocoon. In Slide a user can have 1 or more roles (?, see remarks further
> on). In Cocoon a user has zero or 1 role.

This comes from the fact that I wanted to use the authentification
framework from Carsten, which currently only one role supports.

> 5. I not sure whether order of the vector is important. But if it is, and it
> seems so for Cocoon, could then the order of the Class.getInterfaces() be
> different on different Virtual Machines?
>
> And suppose that every Virtual Machine maintains the order as specified in
> the source file. How can one guarantee that future developers specify the
> intended order?

At the moment the future of the Slide block is unclear. I have implemented
a first bridge between Slide and Cocoon, but this seems more to be a
one-man show. To keep this block alive I need support from others.

So, if you want to enhance the code base, when are patches welcome.

Stephan.


---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org