cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <>
Subject Re: [RT] Cocoon, JAAS, and Sitemap
Date Thu, 21 Jun 2001 20:14:28 GMT
Martin Man wrote:
> hi,
>         I agree with you completely (although must say that haven't got a
> chance to take a look at JAAS deeply) because I was also already thinking
> about the uniform API for authentication (to be incorporated with validators -
> session creation, etc.)...

Quick summary:  JAAS is Java's version of PAM for your application.  It is
                pluggable, configurable, and allows you to control how information
                is displayed.

>         ... and I've seen that until now we (me) are rather duplicating lot of
> things that have been done by servlet api's basic-auth and form-auth (which
> are IMO useless for cocoon itself, cause they can protect only whole servlet)

This is true.  I don't like the Servlet API's "auth" methods because they are
not customizable, and you can't make it work from your own database without
hacking the ServletEngine.

>         ... and I also would like to see it embeded somewhere in the sitemap
> syntax, because resource protection and authentication is part of every webapp
> nowadays so why still hack around with some custom-made actions, validators,
> etc. (not even mentioning possible kerberos incorporation)... would this be
> possible with JAAS easily (presumming sitemap or cocoon.xconf will be
> involved)... something like PAM under linux is doing

That was my whole point.  You would be able to allow only certain Principals
to view certain pages.

> rgds,
> martin
> On Thu, Jun 21, 2001 at 01:31:30PM -0400, Berin Loritsch wrote:
> > Ladies and Gentlemen,
> >
> > I have been giving alot of thought to possible security models and
> > access authorization architectures lately.  Since Java has released
> > Java Authentication and Authorization Services (JAAS), I realized
> > that this was a standard way I could have all my companies apps
> > authenticate and authorize users in a standard manner.  I have never
> > really liked the Servlet API's methods of authentication of end
> > users because you could not design your own ways of testing the
> > authentication.  If you did, you could not take your application
> > to another Servlet Container.
> >
> > As what I am about to outline will affect some semantics of the
> > Sitemap, this is something that would have to be affected in version
> > 2.1 or later of Cocoon.  JAAS has some very interesting ways of
> > creating your own LoginModules that set up authorizations, etc.
> > When there is need of feedback from the LoginModule, it uses a
> > CallbackHandler.  The CallbackHandler will give a standard list
> > of questions and ways of responding to the questions.  This is
> > straightforward.
> >
> > At first you might think that you could create a Generator that
> > was a CallbackHandler and an Action that populated the Callback
> > array with the answers.  While this is part of the solution, the
> > answer is more complicated.  JAAS opperates by obtaining a LoginContext
> > for a login session initialized with the appropriate callbackhandler
> > and other information.  You will then call the login() method
> > on that LoginContext.  After the login is fully authenticated,
> > control returns to the login() method.  This is pretty circuitous.
> >
> > The full solution requires that the login() method be called from
> > the Sitemap.  We would need to create a <map:handle-login/> entry
> > in the pipeline with the transformer and serializer set up.  We would
> > also need to specify whether a client must be logged in for a specific
> > pipeline.  Lastly, we need to have a JAAS executePipelineAction
> > that would be executed as a specific Subject.  Lastly we would need
> > some Role based Permissions.
> >
> > I think the higher sophistication of JAAS and the fact that solutions
> > are portable and customizable for the system is a benefit we can't
> > ignore.  For Cocoon to be taken seriously in corporate settings where
> > secure information is prevalent, we need to take advantage of this
> > security model.
> >
> > Please give me some feedback.
> --
> -------------------------------------------------------------------------------
> "Only dead fish swims with a stream"
> gpg_key_available:
> gpg_key_fingerprint: 2CC0 4AF6 92DA 5CBF 5F09  7BCB 6202 7024 6E06 0223
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, email:
View raw message