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: http://globales.cz/~mman/martin.man.gpg
> gpg_key_fingerprint: 2CC0 4AF6 92DA 5CBF 5F09 7BCB 6202 7024 6E06 0223
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
S/MIME Cryptographic Signature
