[Q] SunRise roles?

[Per Kreipke <pe...@onclave.com>]

I can't figure out how or where the SunRise <role> part of authentication is
used.

Can it be used in the AuthAction to limit access by roles?

Is there an example of using them someplace?

When are all the users with a given role queried?

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:     <co...@xml.apache.org>
For additional commands, e-mail:   <co...@xml.apache.org>

RE: [Q] SunRise roles?

[Carsten Ziegeler <cz...@s-und-n.de>]

Per Kreipke wrote:
> > >
> > Hmm, no - the Nodes itself have to be copied before, so the application
> > can not accidentally change the nodes.
> 
> Ah, interesting, I had actually noticed that they were 'live' and was
> thinking of using that fact. Clearly a no-no :-)
> 
> You mean: nodes have to be cloned to be returned in the list.
> 
Yes.

> > > If not, I just might send that patch ;-)
> >
> > Great!
> 
> Time permitting ;-)
> 
I know this one...

> > In fact, you don't have to distinguish - it makes no difference
> > when using the context.
> 
> Sure, I understood that, the reason I'm asking is to determine whether or
> not I need to do the NodeList work discussed above. E.g. if I don't need
> anything from context ABC and XYZ and those are the only two that use
> SessionContextImpl (which doesn't return NodeLists) then I may not bother
> doing the work discussed above.
> 
Ok - the contexts you create yourself have the full support, so you can get
a NodeList from them - all others maintained by the framework are somewhere
limited.

Carsten


---------------------------------------------------------------------
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:     <co...@xml.apache.org>
For additional commands, e-mail:   <co...@xml.apache.org>

RE: [Q] SunRise roles?

[Per Kreipke <pe...@onclave.com>]

> > > > Aside: if I return a list of comma separated roles could the
> > > > portal still be
> > > > made to work?
> > > >
> > > Yes, it should still work.
> >
> > The portal knows enough to tokenize the role string?
> >
> Rethinking about this, it's a little bit difficult.
> The portal uses the role name to build the profile, which means
> a profile for the role is used in this process.
> So the portal needs one role to build the profile.

Right. Sounds like it's a 'profile selector', not a true role (e.g. not a
group, or set of permissions, etc).

I can also understand the need for a simplification where each user gets
only one profile but couldn't one do something where the user's profile is
the union of all profiles from all their roles?

> > > > - I'm not clear why the SessionContextImpl doesn't implement
> > some of the
> > > > functions like getNodeList(String path).
> > > >
> > > Reason is simple: Lazy developer. Send a patch :)
> >
> >
> > It's not inherent in the fact that the 'sunRise' context spans the
> > authentication, request, response and application XML? There's no
> > problem in
> > your mind with returning NodeLists from across them?
> >
> Hmm, no - the Nodes itself have to be copied before, so the application
> can not accidentally change the nodes.

Ah, interesting, I had actually noticed that they were 'live' and was
thinking of using that fact. Clearly a no-no :-)

You mean: nodes have to be cloned to be returned in the list.

> > If not, I just might send that patch ;-)
>
> Great!

Time permitting ;-)

> > > > Thoughts for doing multiple roles:
> > > >
> > > > + comma separated list of roles inside <role> (yes, sounds
> > flaky doesn't
> > > > it).
> > > >
> > > It's not a nice solution, but should work.
> >
> > And you mentioned above that the portal will accept comma
> delimited roles
> > within <role> already (e.g. it isn't doing an equals() but some kind of
> > tokenization?
> >
> Ok, it will not work.
>
> > > > + add to the <data> section
> > > >
> > > Yes, this is the solution others use (afaik).
> >
> > Really? Others have done this? Anyone posted anything?
>
> I know customers of us which did this.

Ah.

> > > > Aside: what contexts (besides 'sunRise') is the
> > SessionContextImpl used
> > > > instead of SimpleSessionContext?
> > > >
> > > What do you mean? Why the SessionContextImpl is used instead of the
> > > SimpleSessionContext?
> >
> > Well, that is the question really. But I'm also curious if I use
> > <sunshine:getxml> when I'm hitting SimpleSessionContext and when
> > I'm hitting
> > SessionContextImpl.
> >
> In fact, you don't have to distinguish - it makes no difference
> when using the context.

Sure, I understood that, the reason I'm asking is to determine whether or
not I need to do the NodeList work discussed above. E.g. if I don't need
anything from context ABC and XYZ and those are the only two that use
SessionContextImpl (which doesn't return NodeLists) then I may not bother
doing the work discussed above.

> One note about multiple roles:
>
> The authentication framework was designed with the idea that a user
> has only one role at a time. She is either admin, user or guest - but
> not all at the same time. Of course a user can have different roles
> over time.
> But a login specifies exactly one role for the duration of the session.
>
> If you look at a portal for example, this makes sense. You have a portal
> configuration for an admin and one for a usual user. At some point
> of time you have to decide what portal to display for the user - you
> can't display both or somehow combine them.
>
> So the "authentication/role" information should be seen as
> "current role" - it does not cover the possible roles the user could
> also have.
>
> If someone has a good idea on how to combine these efforts, let's do it.

I think the portal's needs are a separate question from correctly
implementing roles so that SunRise is actually a complete
login/authentication package.

If multiple roles aren't possible, for example, I'll have to use container
managed security to get multiple roles and then I won't have all the great
session and config management stuff you did.

I think that both needs can be met by:

- extending roles to allow multiple roles (either through comma separated
list of roles in current <authentication> schema or through a different
schema [e.g. <roles><role>...</role></roles>])

- extending the <authentication> schema to identify which role determines
the profile to use in the portal. E.g.
<authentication><profile>foobar</profile>...</authentication> That should be
a separate concern of just the portal code.

- lastly, integrating with container managed security would be a real nice
to have.

Comments?

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:     <co...@xml.apache.org>
For additional commands, e-mail:   <co...@xml.apache.org>

RE: [Q] SunRise roles?

[Per Kreipke <pe...@onclave.com>]

Any comments on previous message?

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:     <co...@xml.apache.org>
For additional commands, e-mail:   <co...@xml.apache.org>

RE: [Q] SunRise roles?

[Per Kreipke <pe...@onclave.com>]

> > Ah, philosophy :-)
> >
> Yupp!
>
> Ok, I think we reached a state where it's difficult to say who is right
> and who is wrong.
>
> Personally, I think that the meaning of 'groups' and roles is mixed
> somewhere in the servlet spec. *My* understanding is that a person
> can be in several groups at a time but has at once time only exactly
> one role. This understanding might be right or wrong, doesn't matter,
> at least these are only words.
>
>
> >
> > 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.
>
> No, I didn't want to indicate that. Roles may be disjunctive (I hope this
> is the right word).

Ok. That sounds like my second example.

> > > 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?
> >
> When a user is in the process of being authenticated, the framework calls
> the authentication pipeline of the handler. For a successful
> authentication,
> this pipeline returns the authentication XML. You can simple extend
> this XML, so that it has an additional <roles> entry parallel to <role>.
> So, you can return
> <authentication>
>    <ID/>
>    <role/> <!-- still optional, but required by the portal framework -->
>    <roles>a,b,c</roles>
> </authentication>

Ok. I was putting it in the <data> section (the docs made me think that was
required, I'm glad it's not). And the <roles> will still be accessible
through the getxml() calls/tags.

> > > 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.
> >
> So, in your authentication resource, you have to fill the <roles> entry,
> this can be done by calling the servlet api and getting the roles
> information
> from there.
> For testing against a role you have to write your own code/component.

Right, that I got.

In summary, to use the portal, I would need to stick to one role at a time
(e.g. in <role>). I simply extend the notion of <roles> myself.

Thanks for your time,

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:     <co...@xml.apache.org>
For additional commands, e-mail:   <co...@xml.apache.org>

RE: [Q] SunRise roles?

[Carsten Ziegeler <cz...@s-und-n.de>]

Per Kreipke wrote:
>
> Ah, philosophy :-)
>
Yupp!

Ok, I think we reached a state where it's difficult to say who is right
and who is wrong.

Personally, I think that the meaning of 'groups' and roles is mixed
somewhere in the servlet spec. *My* understanding is that a person
can be in several groups at a time but has at once time only exactly
one role. This understanding might be right or wrong, doesn't matter,
at least these are only words.


>
> 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.

No, I didn't want to indicate that. Roles may be disjunctive (I hope this
is the right word).

>
> > 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?
>
When a user is in the process of being authenticated, the framework calls
the authentication pipeline of the handler. For a successful authentication,
this pipeline returns the authentication XML. You can simple extend
this XML, so that it has an additional <roles> entry parallel to <role>.
So, you can return
<authentication>
   <ID/>
   <role/> <!-- still optional, but required by the portal framework -->
   <roles>a,b,c</roles>
</authentication>

>
> > 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.
>
So, in your authentication resource, you have to fill the <roles> entry,
this can be done by calling the servlet api and getting the roles
information
from there.
For testing against a role you have to write your own code/component.

Carsten


---------------------------------------------------------------------
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:     <co...@xml.apache.org>
For additional commands, e-mail:   <co...@xml.apache.org>

RE: [Q] SunRise roles?

[Per Kreipke <pe...@onclave.com>]

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:     <co...@xml.apache.org>
For additional commands, e-mail:   <co...@xml.apache.org>

RE: [Q] SunRise roles?

[Carsten Ziegeler <cz...@s-und-n.de>]

Per Kreipke wrote:
>
>
> 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.

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.

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.

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

Carsten


---------------------------------------------------------------------
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:     <co...@xml.apache.org>
For additional commands, e-mail:   <co...@xml.apache.org>

RE: [Q] SunRise roles?

[Per Kreipke <pe...@onclave.com>]

Carsten,

I'm going to rush this next sentence out because I know that you're done for
the day and then I won't have ideas to work on while you're away :-), then
I'll reply to your previous note.


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.



Now on to reply...

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:     <co...@xml.apache.org>
For additional commands, e-mail:   <co...@xml.apache.org>

RE: [Q] SunRise roles?

[Carsten Ziegeler <cz...@s-und-n.de>]

Per Kreipke wrote:
> > > Aside: if I return a list of comma separated roles could the
> > > portal still be
> > > made to work?
> > >
> > Yes, it should still work.
> 
> The portal knows enough to tokenize the role string?
> 
Rethinking about this, it's a little bit difficult.
The portal uses the role name to build the profile, which means
a profile for the role is used in this process. 
So the portal needs one role to build the profile.

> > > - I'm not clear why the SessionContextImpl doesn't implement 
> some of the
> > > functions like getNodeList(String path).
> > >
> > Reason is simple: Lazy developer. Send a patch :)
> 
> 
> It's not inherent in the fact that the 'sunRise' context spans the
> authentication, request, response and application XML? There's no 
> problem in
> your mind with returning NodeLists from across them?
> 
Hmm, no - the Nodes itself have to be copied before, so the application
can not accidentally change the nodes.

> If not, I just might send that patch ;-)

Great!

> 
> > > Thoughts for doing multiple roles:
> > >
> > > + comma separated list of roles inside <role> (yes, sounds 
> flaky doesn't
> > > it).
> > >
> > It's not a nice solution, but should work.
> 
> And you mentioned above that the portal will accept comma delimited roles
> within <role> already (e.g. it isn't doing an equals() but some kind of
> tokenization?
> 
Ok, it will not work.

> > > + add to the <data> section
> > >
> > Yes, this is the solution others use (afaik).
> 
> Really? Others have done this? Anyone posted anything?

I know customers of us which did this.

> 
> > > Aside: what contexts (besides 'sunRise') is the 
> SessionContextImpl used
> > > instead of SimpleSessionContext?
> > >
> > What do you mean? Why the SessionContextImpl is used instead of the
> > SimpleSessionContext?
> 
> Well, that is the question really. But I'm also curious if I use
> <sunshine:getxml> when I'm hitting SimpleSessionContext and when 
> I'm hitting
> SessionContextImpl.
> 
In fact, you don't have to distinguish - it makes no difference
when using the context.

One note about multiple roles:

The authentication framework was designed with the idea that a user
has only one role at a time. She is either admin, user or guest - but
not all at the same time. Of course a user can have different roles
over time. 
But a login specifies exactly one role for the duration of the session.

If you look at a portal for example, this makes sense. You have a portal
configuration for an admin and one for a usual user. At some point
of time you have to decide what portal to display for the user - you
can't display both or somehow combine them.

So the "authentication/role" information should be seen as
"current role" - it does not cover the possible roles the user could
also have.

If someone has a good idea on how to combine these efforts, let's do it.

Carsten

---------------------------------------------------------------------
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:     <co...@xml.apache.org>
For additional commands, e-mail:   <co...@xml.apache.org>

RE: [Q] SunRise roles?

[Per Kreipke <pe...@onclave.com>]

Sorry, previous reply was incomplete...

> > Follow up questions:
> >
> > - is there an equivalent call to
> HTTPServletRequest.isUserInRole() against
> > the authentication context?
> >
> No (not yet). From java code you can get the content of
> "/authentication/role"
> and test it against your value. From a pipeline, you have to get the
> role using "session:getxml" and then test it in a stylesheet...For such
> tests, I always wanted to add a "session:testxml"...
>
> > - From what I can tell, the SunRise code doesn't support the notion of
> > multiple roles per user. It makes the SunRise Authentication
> support not a
> > complete replacement for container security.  Perhaps that
> wasn't the goal
> > but it's something people will look for.
> >
> > What's the background for that? Do you think it could be overcome easily
> > (how?)?
> Yes, there are several solutions, as you pointed out below:
>
> >
> > Aside: if I return a list of comma separated roles could the
> > portal still be
> > made to work?
> >
> Yes, it should still work.

The portal knows enough to tokenize the role string?

> > - I'm not clear why the SessionContextImpl doesn't implement some of the
> > functions like getNodeList(String path).
> >
> Reason is simple: Lazy developer. Send a patch :)


It's not inherent in the fact that the 'sunRise' context spans the
authentication, request, response and application XML? There's no problem in
your mind with returning NodeLists from across them?

If not, I just might send that patch ;-)

> > Thoughts for doing multiple roles:
> >
> > + comma separated list of roles inside <role> (yes, sounds flaky doesn't
> > it).
> >
> It's not a nice solution, but should work.

And you mentioned above that the portal will accept comma delimited roles
within <role> already (e.g. it isn't doing an equals() but some kind of
tokenization?

> > + add to the <data> section
> >
> Yes, this is the solution others use (afaik).

Really? Others have done this? Anyone posted anything?

> > <authentication>
> >   <ID>per</ID>
> >   <role>unused</role>
> >   <data>
> >     <roles>
> >       <role>manager</role>
> >       <role>ibm</role>
> >       <role>admin</role>
> >     </roles>
> >   </data>
> > </authentication>
> >
> > But then I immediately ran into trouble trying to iterate over all the
> > nested <role>s inside <roles> since SessionContextImpl doesn't implement
> > some of the xpath functions.
>
> Again, this is only due to a lazy developer - you could implement them.

They're already in SimpleSessionContext, I'll copy that code.

> > Aside: what contexts (besides 'sunRise') is the SessionContextImpl used
> > instead of SimpleSessionContext?
> >
> What do you mean? Why the SessionContextImpl is used instead of the
> SimpleSessionContext?

Well, that is the question really. But I'm also curious if I use
<sunshine:getxml> when I'm hitting SimpleSessionContext and when I'm hitting
SessionContextImpl.

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:     <co...@xml.apache.org>
For additional commands, e-mail:   <co...@xml.apache.org>

RE: [Q] SunRise roles?

[Per Kreipke <pe...@onclave.com>]

> > Follow up questions:
> >
> > - is there an equivalent call to
> HTTPServletRequest.isUserInRole() against
> > the authentication context?
> >
> No (not yet). From java code you can get the content of
> "/authentication/role"
> and test it against your value. From a pipeline, you have to get the
> role using "session:getxml" and then test it in a stylesheet...For such
> tests, I always wanted to add a "session:testxml"...
>
> > - From what I can tell, the SunRise code doesn't support the notion of
> > multiple roles per user. It makes the SunRise Authentication
> support not a
> > complete replacement for container security.  Perhaps that
> wasn't the goal
> > but it's something people will look for.
> >
> > What's the background for that? Do you think it could be overcome easily
> > (how?)?
> Yes, there are several solutions, as you pointed out below:
>
> >
> > Aside: if I return a list of comma separated roles could the
> > portal still be
> > made to work?
> >
> Yes, it should still work.

The portal kn
>
> > - I'm not clear why the SessionContextImpl doesn't implement some of the
> > functions like getNodeList(String path).
> >
> Reason is simple: Lazy developer. Send a patch :)

It's not inherent in the fact that the 'sunRise' context spans the
authentication, request, response and application XML? There's no problem in
your mind with returning NodeLists from across them?

If not, I just might send that patch ;-)

> > Thoughts for doing multiple roles:
> >
> > + comma separated list of roles inside <role> (yes, sounds flaky doesn't
> > it).
> >
> It's not a nice solution, but should work.

And you mentioned above that the portal will accept comma delimited roles
within <role> already (e.g. it isn't doing an equals() but some kind of
tokenization?

> > + add to the <data> section
> >
> Yes, this is the solution others use (afaik).

Really? Others have done this? Anyone posted anything?

> > <authentication>
> >   <ID>per</ID>
> >   <role>unused</role>
> >   <data>
> >     <roles>
> >       <role>manager</role>
> >       <role>ibm</role>
> >       <role>admin</role>
> >     </roles>
> >   </data>
> > </authentication>
> >
> > But then I immediately ran into trouble trying to iterate over all the
> > nested <role>s inside <roles> since SessionContextImpl doesn't implement
> > some of the xpath functions.
>
> Again, this is only due to a lazy developer - you could implement them.

They're already in SimpleSessionContext, I'll copy that code.

> > Aside: what contexts (besides 'sunRise') is the SessionContextImpl used
> > instead of SimpleSessionContext?
> >
> What do you mean? Why the SessionContextImpl is used instead of the
> SimpleSessionContext?

Well, that is the question really but I'm also curious when I use
<sunshine:getxml> when I'm hitting SimpleSessionContext and when I'm hitting
SessionContextImpl.

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:     <co...@xml.apache.org>
For additional commands, e-mail:   <co...@xml.apache.org>

RE: [Q] SunRise roles?

[Carsten Ziegeler <cz...@s-und-n.de>]

Per Kreipke wrote:
>
> Follow up questions:
>
> - is there an equivalent call to HTTPServletRequest.isUserInRole() against
> the authentication context?
>
No (not yet). From java code you can get the content of
"/authentication/role"
and test it against your value. From a pipeline, you have to get the
role using "session:getxml" and then test it in a stylesheet...For such
tests, I always wanted to add a "session:testxml"...

> - From what I can tell, the SunRise code doesn't support the notion of
> multiple roles per user. It makes the SunRise Authentication support not a
> complete replacement for container security.  Perhaps that wasn't the goal
> but it's something people will look for.
>
> What's the background for that? Do you think it could be overcome easily
> (how?)?
Yes, there are several solutions, as you pointed out below:

>
> Aside: if I return a list of comma separated roles could the
> portal still be
> made to work?
>
Yes, it should still work.

> - I'm not clear why the SessionContextImpl doesn't implement some of the
> functions like getNodeList(String path).
>
Reason is simple: Lazy developer. Send a patch :)

> Thoughts for doing multiple roles:
>
> + comma separated list of roles inside <role> (yes, sounds flaky doesn't
> it).
>
It's not a nice solution, but should work.

> + add to the <data> section
>
Yes, this is the solution others use (afaik).

> <authentication>
>   <ID>per</ID>
>   <role>unused</role>
>   <data>
>     <roles>
>       <role>manager</role>
>       <role>ibm</role>
>       <role>admin</role>
>     </roles>
>   </data>
> </authentication>
>
> But then I immediately ran into trouble trying to iterate over all the
> nested <role>s inside <roles> since SessionContextImpl doesn't implement
> some of the xpath functions.

Again, this is only due to a lazy developer - you could implement them.

>
> Aside: what contexts (besides 'sunRise') is the SessionContextImpl used
> instead of SimpleSessionContext?
>
What do you mean? Why the SessionContextImpl is used instead of the
SimpleSessionContext?

HTH
Carsten


---------------------------------------------------------------------
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:     <co...@xml.apache.org>
For additional commands, e-mail:   <co...@xml.apache.org>

RE: [Q] SunRise roles?

[Per Kreipke <pe...@onclave.com>]

> > I can't figure out how or where the SunRise <role> part of
> > authentication is
> > used.
> >
> It is used in the (sunSpot) portal framework for generating
> the profile of a user. But apart from that it's not use.

Ok.

> > Can it be used in the AuthAction to limit access by roles?
> >
> You can write your own component for this, but afaik there
> is currently none already available.
>
> > Is there an example of using them someplace?
> >
> Besides the (big) portal code: I think, no.
>
> > When are all the users with a given role queried?
> >
> For a running system: never. Only the user management web
> application where you can add a new user, add roles etc.
> fetches all users for a given role to make them editable.

Ok.

Follow up questions:

- is there an equivalent call to HTTPServletRequest.isUserInRole() against
the authentication context?

- From what I can tell, the SunRise code doesn't support the notion of
multiple roles per user. It makes the SunRise Authentication support not a
complete replacement for container security.  Perhaps that wasn't the goal
but it's something people will look for.

What's the background for that? Do you think it could be overcome easily
(how?)?

Aside: if I return a list of comma separated roles could the portal still be
made to work?

- I'm not clear why the SessionContextImpl doesn't implement some of the
functions like getNodeList(String path).

Thoughts for doing multiple roles:

+ comma separated list of roles inside <role> (yes, sounds flaky doesn't
it).

+ add to the <data> section

<authentication>
  <ID>per</ID>
  <role>unused</role>
  <data>
    <roles>
      <role>manager</role>
      <role>ibm</role>
      <role>admin</role>
    </roles>
  </data>
</authentication>

But then I immediately ran into trouble trying to iterate over all the
nested <role>s inside <roles> since SessionContextImpl doesn't implement
some of the xpath functions.

Aside: what contexts (besides 'sunRise') is the SessionContextImpl used
instead of SimpleSessionContext?

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:     <co...@xml.apache.org>
For additional commands, e-mail:   <co...@xml.apache.org>

RE: [Q] SunRise roles?

[Carsten Ziegeler <cz...@s-und-n.de>]

> -----Original Message-----
> From: Per Kreipke [mailto:per@onclave.com]
> Sent: Monday, August 12, 2002 7:34 PM
> To: cocoon-users@xml.apache.org
> Subject: [Q] SunRise roles?
> 
> 
> I can't figure out how or where the SunRise <role> part of 
> authentication is
> used.
> 
It is used in the (sunSpot) portal framework for generating
the profile of a user. But apart from that it's not use.

> Can it be used in the AuthAction to limit access by roles?
> 
You can write your own component for this, but afaik there
is currently none already available.

> Is there an example of using them someplace?
> 
Besides the (big) portal code: I think, no.

> When are all the users with a given role queried?
> 
For a running system: never. Only the user management web
application where you can add a new user, add roles etc.
fetches all users for a given role to make them editable.

Carsten

---------------------------------------------------------------------
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:     <co...@xml.apache.org>
For additional commands, e-mail:   <co...@xml.apache.org>