Michael,
Regarding the use of authentication with JAAS, I think
> Cocoon would be simply another JAAS client, using an application server
> to authenticate against.
Yes. Being a JAAS clint is application specific.
All that needs to be implemented is a login callback handler, which is
certainly specific for each application domain. It can be either file based
or do database lookup or a remote web service call.
Therefore I don't see how a generic Cocoon component can further help with
authentication.
> >Security rules are URL based which fits nice with Cocoon's URL based
content
> >management.
> >
> I do not yet think leaving security constrains to the servlet container
> is sufficient. Handling security in a different place than the sitemap
> makes it possible to get the security contrains "out of sync" with the
> URL space the sitemap defines.
Probabaly so.
Since security is a very sensitive matter.
I generally prefer that only a few senior developers have control over the
URL space security.
This is why the separation in web.xml suits my needs well.
As there are other matchers that are not
> URL-based, solving security demands in these cases requires additional
> work that is dependent on the servlet container (as far as I
> understand). What is your opinion on these aspects ?
I am not sure what you mean here.
Can you give me an example?
> As there are other solutions such as the security contrains in web.xml
> available, having authentication components available as optional
> sitemap components would serve those who would like to use JAAS in that
> manner.
I can see the value of a role based matcher, which will help organize
content better.
> I haven't used the Auth/sunRise im my current project as I am not
> satisfied with them for various reasons, including the aspect of
> centralizing security management in an application server serving the
> logic, not in a presentation-oriented servlet container. Maybe I
> misunderstood your last sentence ("integration with the J2EE containers'
> security context"), but in our case, servlet containers and application
> servers are not necessarily running in the same VM or hosted on the same
> machine, therefore we try to use JNDI or something in that direction.
Sure.
Distributed security context is one of the reasons why I would leave
security to the J2EE container.
When you provide a callback for JAAS, no matter which server takes the
servlet request, the principal gets carried over to all participating EJBs.
The J2EE container makes the principal available via JNDI to any participant
in the request be it local or remote.
I think we are on the same page.
Best,
Ivelin
>
> >Regards,
> >
> >Ivelin
> >
> >
> Best regards,
>
> Michael Hartle,
> Hartle & Klug GbR
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
