Fw: Authentication for Cocoon [JAAS , JBoss, WebLogic, etc.]

[Ivelin Ivanov <iv...@apache.org>]

Thought some people might be interested in our off-line discussion with
Michael.


----- Original Message -----
From: "Ivelin Ivanov" <iv...@apache.org>
To: "Michael Hartle" <mh...@hartle-klug.com>
Sent: Thursday, October 24, 2002 10:27 PM
Subject: Re: Authentication for Cocoon [JAAS , JBoss, WebLogic, etc.]


>
> Michael,
>
> After reading some more on JAAS, JBoss and using my knowledge with
WebLogic,
> I came to the conclusion that security management should be left out of
> Cocoon.
>
> It belongs to the J2EE containers.
>
> Cocoon's responsibility should remain clear and simple:
> 1) organizing complex sites and
> 2) gluing presentation, content and logic.
>
> JAAS is a robust and widely accepted security API.
> The callback mechanisms for JBoss, WebLogic and any other app server are
> different, however the declarative security remains the same.
>
> I find the security constrain syntax in web.xml files simple and clear
> enough. It is perfectly applicable for Cocoon application, since Cocoon is
> obviously a Java webapp.
> Security rules are URL based which fits nice with Cocoon's URL based
content
> management.
>
> I may sound destructive and controversial, but as of now I believe that
the
> Authentication module should not be a core Cocoon module and it should not
> appear as such in the documentation.
> Maybe a separate block. It brought quite a bit of confusion to me while I
> was trying to understand its unique value for Cocoon applications. All the
> applications that I have written for Cocoon require integration with the
> J2EE containers' security context and do not need the Auth (aka sunRise)
> component.
>
> I think that Cocoon simply needs a HOW-TO document show casing a small
> project which uses J2EE security for a Cocoon application. JBoss or plain
> Tomcat as container would be nice.
> Please consider focusing your time on a HOW-TO rather than new components.
>
>
> Regards,
>
> Ivelin
>
>
>
>
>
>
> ----- Original Message -----
> From: "Michael Hartle" <mh...@hartle-klug.com>
> To: "Ivelin Ivanov" <iv...@apache.org>
> Sent: Thursday, October 24, 2002 5:56 AM
> Subject: JAAS Authentication for Cocoon
>
>
> >   Hello Ivelin,
> >
> > I recently had the chance to start thinking about JAAS authentication
> > with a friend, and we came to some conclusions that I still have to
> > collect in an electronical form concerning the details - currently the
> > details of the concept are spread on about 12 bills from a bar we
> > occasionally visit :-).
> >
> > In short, we thought about implementing a JAASAuthenticationAction
> > (taking username, password, server and JNDI reference as parameters) to
> > protect sitemap resources and a JAASTransformer (taking username,
> > password as parameters) capable of filtering specially tagged sections
> > (something along <jaas:authenticate server="abc" ref="jndi://...")
> > depending on whether the user can be authenticated in that specific
> > security domain.
> >
> > Regarding the coupling with an application server, we thought about
> > exposing a javax.security.auth.login.Configuration object for each
> > security domain into the JNDI directory of the application server - we
> > haven't yet tested whether his works or not, so the concept yet has to
> > be tested and proven. Exposure of the Configuration object in the JNDI
> > directory can be done via an MBean which is defined in the
> > J2EE/Management-related specs, so this should be widely deployable. If
> > this works as expected, the Configuration object can be retrieved by
> > Cocoon via a JNDI lookup and set up for usage via
> > Configuration.setConfiguration(remoteConfiguration), allowing normal
> > LoginContext-based operation to be based on remote JAAS configurations.
> >
> > These were our first thoughts in this direction; what do you think ?
> >
> > Best regards,
> >
> > Michael Hartle,
> > Hartle & Klug GbR
> >
>


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org