You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Berin Loritsch <bl...@apache.org> on 2001/06/21 19:31:30 UTC

[RT] Cocoon, JAAS, and Sitemap

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.

Re: [RT] Cocoon, JAAS, and Sitemap

Posted by Berin Loritsch <bl...@apache.org>.
Kasper Nielsen wrote:
> 
> ----- Original Message -----
> From: "Berin Loritsch" <bl...@apache.org>
> To: <co...@xml.apache.org>
> Sent: Thursday, June 21, 2001 7:31 PM
> Subject: [RT] Cocoon, JAAS, and Sitemap
> 
> >
> > Please give me some feedback.
> 
> Giving up on java 1.2 support??
> 
> from the docs
> JAAS 1.0 supplements the JavaTM 2 Platform, Standard Edition, v 1.3, and
> requires that you have it installed.


For our company, yes.  JDK 1.3 has been around for a while.
JDK 1.3 is available on most systems, except for freeBSD.
Does anyone know what is going on with that effert?

Re: [RT] Cocoon, JAAS, and Sitemap

Posted by Kasper Nielsen <ne...@kav.dk>.
----- Original Message -----
From: "Berin Loritsch" <bl...@apache.org>
To: <co...@xml.apache.org>
Sent: Thursday, June 21, 2001 7:31 PM
Subject: [RT] Cocoon, JAAS, and Sitemap


>
> Please give me some feedback.

Giving up on java 1.2 support??

from the docs
JAAS 1.0 supplements the JavaTM 2 Platform, Standard Edition, v 1.3, and
requires that you have it installed.

- Kasper



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


Re: [RT] Cocoon, JAAS, and Sitemap

Posted by Martin Man <Ma...@seznam.cz>.
On Thu, Jun 21, 2001 at 04:14:28PM -0400, Berin Loritsch wrote:
> 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.
> 

o.k., then I'm enthusiasted and I'm going to study JAAS :-))

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

-- 
-------------------------------------------------------------------------------
"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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Re: [RT] Cocoon, JAAS, and Sitemap

Posted by Berin Loritsch <bl...@apache.org>.
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: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org

Re: [RT] Cocoon, JAAS, and Sitemap

Posted by Martin Man <Ma...@seznam.cz>.
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.)...

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

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


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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org