Carsten, 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" http://us.imdb.com/Title?0041546 - 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. Examples: 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 to: {manager,employee,internal,afternoon} 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 start/look? > 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. Per --------------------------------------------------------------------- Please check that your question has not already been answered in the FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html> To unsubscribe, e-mail: <[EMAIL PROTECTED]> For additional commands, e-mail: <[EMAIL PROTECTED]>
