cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Per Kreipke" <>
Subject RE: [Q] SunRise roles?
Date Thu, 15 Aug 2002 15:03:19 GMT

Ah, philosophy :-)

> > I think that the restriction you describe (one role per user)
> > means that the
> > SunRise authentication is potentially mis-using the word 'role'. You're
> > using it to denote a profile name, nothing more. It'll never
> > really replace
> > (or integrate with) roles in the Servlet or permissions sense if it's
> > restricted to one role at a time.
> >
> No, I don't agree with your definition of 'role' - take acting as an
> example. A role in acting is one single role and not a bunch of possible
> roles an actor plays. - If an actor plays several persons he plays several
> roles but not a role with a comma separated list.

Just to provide some light hearted counter point, some of which relates to
Cocoon security:

- actors can play more than one role. Alec Guinness plays 8 of them in "Kind
Hearts and Coronets"

- within a play, roles can play more than one role. Take any play within a
play where the characters play other characters.

- actors often direct the things they're in. Kenneth Branaugh, Kelsey
Grammer, etc.

> If you login into a system (and this is not related to Cocoon but to any
> system), you get a specific role with this login - you are either manager,
> administrator, user or guest - you are not at the same time manager and
> guest.
> That doesn't make sense.
> You can be either manager and guest, theoretically - but at one
> time you are
> only one of them. And you can switch your role.

Two comments:

1. you're saying that users can only inhabit one role within a set of
related roles. Let's say that's true.

The Servlet spec, however, clearly allows more than a single set of roles.

level: [manager,contributor,guest]
status: [employee,consultant]
company: [client,internal]
shift: [morning,afternoon,night]

To denote the full set of roles that I inhabit, it would have to be similar


E.g. multiple roles. Which the Servlet spec supports.

2. In your example, I think you're indicating that some roles are 'larger'
than others and that the larger ones contain the smaller ones. E.g. the
rights of the following roles from broadest to narrowest:

super > manager > contributor > reader > registered-guest > unregistered

Even if that wasn't your point, let me just say that (though perhaps not
ideal), there are two ways to model that set:

- each broader role includes the permissions of the next narrower one, and
adds to that set. Think nested circles in a Ven diagram, the typical way
people think about it. This way, as you mention, users have only need one
role at a time, and promotion means changing that role.

- or, each role is only the difference from any other set and the total set
of permissions is the union of all the roles you want. Think adjacent
circles in a Ven diagram. This way, users get a list of all the roles they
inhabit. In fact, they _are_ "at the same time manager and guest."

I agree, this is in fact _not_ such a good idea, that's really what
permissions are for, not roles, _but_ my point is that the Servlet spec
doesn't say how to do authentication and authorization, it just provides a
general mechanism, which SunRise is not currently expressive enough for.

> If you need this list of possibilities, I would suggest to not use the
> 'role' entry, but a 'roles' entry. The authentication framework
> is flexible
> and can handle this automatically.

Right, <roles> was something I mentioned earlier but it already does so?
That's news to me :-) How does it do so automatically? Where do I

> So, the authentication framework fits nicely into the servlet
> role handling.

Uh, I think I missed a leap somewhere :-)

Can you please give me a pointer on what you mean? Are you talking about
returning <roles> inside <data> and then selecting it when needed? Are you
saying that it can implement Realm based security? You lost me, sorry.


Please check that your question  has not already been answered in the
FAQ before posting.     <>

To unsubscribe, e-mail:     <>
For additional commands, e-mail:   <>

View raw message