Re: Slide - Cocoon principal roles

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

on 7/31/03 15:48, Taisuke Yamada at tai@imasy.or.jp wrote:

Hi Taisuke,

Thank you for your information.

The problem is even somewhat more complicated. I've, probably mistakenly,
assumed that the SlidePrincipalProvider was implementing Cocoon's
PrincipalProvider interface and using Cocoon's Principal, PrincipalGroup and
PrincipalListGenenrator. I assumed that these classes where Cocoon's because
of the packagename org.apache.cocoon.components.repository. But, on the
Cocoon 2.1 web-site apidoc, one cannot find a package
org.apache.cocoon.components.repository.

It looks to me now that these classes are neither integral part of Cocoon,
nor integral part of Slide. Of course I do not know the application of these
classes, but they seemed usable for my purpose for a while. I'd be curious
to know why the author, who sort of had control over the whole thing, just
allowed a single role at to come out of the PrincipalListGenerator. He might
as well have presented all role(s), since Slide would already give this to
him. But then again, this surely was valid for his application. Perhaps my
application is just slightly different.

I'm trying to contact the author of those classes and ask him.

Our problem is more complicated because we want to user to talk to Cocoon.
Then at some point login and be authenticated by a Netware collocated
eDirectory/LDAP server. Slide is used for getting the permissions for
folders (and files) based on the user's name or role(s) and storage.

I'm still trying to put this puzzle together with the bits and pieces at
hand.

With kind regards,
Peter Paulus

> 
> Hi,
> 
> I too, was struggling with Slide role model, so I'll take this
> chance and try to share some information. It'd be great if someone
> in the know can clear all up.
> 
>> 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
> 
> It is possible. It seems you have found that out yourself, but you
> only need a class that implements multiple interfaces, each corresponding
> to specific role. That's why you map RootRole "interface" to root "role"
> while root "user" is mapped to RootRoleImpl "class" that implements it.
> 
>> 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.
> 
> All *Node classes are just an object that represents node in
> tree-style storage structure. Security related checks are done
> in org/apache/slide/security/*.java classes.
> 
>> 3. The vector of roles is build by using refelection on the role
>> implementation class. This presents a (academic) problem.
> 
> Yes, this is a problem, but this wasn't apparent in current Slide
> usage. This happens because there're two hashtables in Slide: table
> that maintains role-to-class (interface) relation and user-to-class
> relation.
> 
> In Slide, role checking is done by hasRole(), which looks up role-to-
> class table and then run a check by "roleClass.isInstance(userObject)".
> This will work even if you have defined new role interface that extends
> existing role. On the other hand, getRoles() looks up user-to-class
> table and only lists up directly implemented interfaces as you have
> pointed out. But since getRoles() is not used for security check, this
> bug was not apparent.
> 
>> 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.
> 
> True. But this one isn't a problem as role interfaces are just a
> placeholder and has no callable method. It is handled as role
> interface if and only if you map it to specific role in Domain.xml.
> Anything else is just ignored.
> 
>> 5. I not sure whether order of the vector is important.
>> [snip]
>> 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:
> 
> Hmm, I'm not sure. It sounds like you're saying Slide needs this
> "broadness" concept just because Cocoon has one.
> 
> But anyway, what you have described is current limitation of Slide
> role model. Slide "role" is so inflexible that Slide "group" is
> actually more closer to use of "role" in other software. It probably
> does not worth much trying to use current Slide role, as this limitation
> is pretty painful. It'd be better to wait until this gets fixed.
> 
> AFAIK, there was an attempt to fix this user/role/group model in
> late 2002. That would have solved many of the problems. I even
> remember seeing actual patch floating around, but I guess that
> effort went nowhere as I still don't see that patch applied in CVS.
> 
> --
> Taisuke Yamada <ta...@imasy.or.jp>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-user-help@jakarta.apache.org


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