--- Matt Raible <[EMAIL PROTECTED]> wrote:
> Hello All,
> 
> I'm in the midst of writing a chapter on Security in
> Web Applications 
> for an upcoming Wrox book.  I want to include a
> demonstration of using 
> JAAS in my sample app, as well as using form-based
> authentication.  
> Would it be possible to do the following with Ant
> and XDoclet?
> 
>      * Use Ant and a task that runs if
> ${enable.jaas} is true

It's possible. There are attributes for targets like
unless="${foo}" and conditional execution 

>      * This task (i.e. jaas) will add a JAAS policy
> file to the webapp, 
> maybe in the WEB-INF/classes directory so it's in
> the classpath


>      * The jaas task will do some token replacement
> in login.jsp to 
> change the form's action from j_security_check to
> something else. 
> Ideally, I wouldn't have to do this.

This can be done by <copy> task. 

>      * The webdoclet task with not merge the
> web-security.xml file into 
> web.xml
>      * The ActionFilter, which I currently use to
> retrieve the user's 
> information, will call the authenticate method and
> route appropriately 
> if JAAS is enabled.
> 
> One thing I really like about form-based
> authentication (besides the 
> ease of setup and no required programming) is that
> it allows users to 
> bookmark pages in your app. When they select that
> bookmark again after 
> logging out, they are prompted for a login and
> routed to the bookmark 
> upon successful authentication. I hope JAAS can do
> this too.

You are mixing up authentication  & session tracking
method. User sessions can be authenticated
via FORM, BASIC and whatever methods. 

Authentication / Authorization kicks in if user
requests URL which is protected. Only difference with
those methods is that in FORM you are redirected
to specific page, and after you submit to
j_security_chek you are redirected back to where you
liked to go first. With BASIC you get user/password
dialog in your browser. BASIC authentication also has
its problems - browser remembers username/password
until restart ( at least netscape )

Authentication information is later stored on user
session. 

You can bookmark pages regardless of authorisation
method. What really matters is session tracking method
- if this is tracked via cookie / certificate - you
are fine. If you use URL mangling, you may (and
certainly will) loose authentication if you try to
call up bookmark - there is wrong session stored. 

I think you try to reinvent the wheel. 
Servet containers are required to provide
authentication by spec. If you configured URLs to
protec in web.xml, it will kick in. It will try to 
obtain your principal/credential ( via BASIC or FORM 
methods ) and store them in a session. 

Then for every request, interceptor/valve will 
authenticate/authorize  it to proceed.

So, no need explicitly reauthenticate user. 

BTW, if you are using jboss/tomcat combo, cached
authentication information will be handed to jboss,
and then authenticated/authorized again for EJB method
calls. 

I had a weird security infrastructure, where I needed
to provide different ( and possibly intersecting )
sets of login names for different web ocntexts, 
all of them accessing the same EJBs. And I also liked
to have numeric user ID for EJB instead of login names
(which were not unique , and possibly one user could
go by different names depending on web context)

I just can not see what XDoclet got to do with it. 
It's just templating engine which renders templates
based on metadata contained in the java sources...

just my EUR 0.02

regards,

=====
Konstantin Priblouda ( ko5tik )    Freelance Software developer
< http://www.pribluda.de > < play java games -> http://www.yook.de >
< render charts online -> http://www.pribluda.de/povray/ >

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Xdoclet-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xdoclet-user

Reply via email to