Re: Custom authentication strategy

Message

thanks for the reply.

indeed its a good article yet it does not answer my basic problem.

i need to be able to authenticate users explicitally from uprotected pages as well.

until now, the only response which suggested a solution state that i can include:

in every JSP. however, i read somewhere that this method can cause problems because you basically take to your hands what belongs to the container.

this seems like a problem that everyone should be facing (unless the application manages security such as in the blueprints).

anymore comments on this issue?

-----Original Message-----
From: Wilfredo Sellado [mailto:wsellado@CYBERJRESOURCES.COM]
Sent: Wednesday, February 18, 2004 9:43 AM
To: J2EEPATTERNS-INTEREST@JAVA.SUN.COM
Subject: Re: Custom authentication strategy

I hope this can give idea.

http://www.onjava.com/pub/a/onjava/2002/06/12/form.html

-----Original Message-----
From: An interest list for Sun Java Center J2EE Pattern Catalog [mailto:J2EEPATTERNS-INTEREST@JAVA.SUN.COM]On Behalf Of Katz Guy
Sent: Wednesday, February 18, 2004 2:27 PM
To: J2EEPATTERNS-INTEREST@JAVA.SUN.COM
Subject: Re: Custom authentication strategy

hi;

in this option, i cannot leverage the container security services.

what i need is to use one of the available mechanisms (basic, form, ...) but be able to explicitly activate them bypassing their 'lazy authentication' behaviour.

thanks.

-----Original Message-----
From: Satyan Prakash [mailto:satyan.prakash@NTLWORLD.COM]
Sent: Tuesday, February 17, 2004 8:35 PM
To: J2EEPATTERNS-INTEREST@JAVA.SUN.COM
Subject: Re: Custom authentication strategy

Or you can use a Servlet Filter in J2EE 1.3 the url pattern for which will be *. In fact you can consolidate all your security checks in this servlet and deploy it as a filter for all web resources.

----- Original Message -----

From: Aaron Tubman

Sent: Monday, February 16, 2004 9:05 AM

Subject: Re: Custom authentication strategy

I suggest using the Dispatcher (see chapter 6) pattern that is initial access point for each request in conjunction with Controller pattern

Something likes this:

Public class Dispathcher extends HttpServlet {

            Private AuthenticationController authenticationController.

            public void doGet(HttpServletRequest request, HttpServletResponse response) {

                        if (!authenticationController.authenticate(request)) {

                                    response.sendRedirect("login");

                                    return;

}

// 'authenticate' method will analyze the validity of this "AuthenticationInfo" cookie.

response.addCookie(new Cookie("AuthenticationInfo", <some encripted info>));

            }

alternatively you can save AuthenticationInfo in your session. In this case Dispatcher require login upon each new user session while cookie can be saved

accros a time (days/months).

-----Original Message-----
From: An interest list for Sun Java Center J2EE Pattern Catalog [mailto:J2EEPATTERNS-INTEREST@JAVA.SUN.COM] On Behalf Of Katz Guy
Sent: Monday, February 16, 2004 10:40 AM
To: J2EEPATTERNS-INTEREST@JAVA.SUN.COM
Subject: Custom authentication strategy

Hi all;
I have a requirement for being able to log in from any page.
I still want my solution to benefit from the container security services.
However, the container will prompt the login page only for protected resource and many of my resource are not protected but I would still like to be able to login from those pages

What are my options here?
Any thoughts will help
Thanks.
==================================================================== Companion Site: http://www.corej2eepatterns.com J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns List Archive: http://archives.java.sun.com/archives/j2eepatterns-interest.html Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to listserv@java.sun.com ==================================================================== Companion Site: http://www.corej2eepatterns.com J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns List Archive: http://archives.java.sun.com/archives/j2eepatterns-interest.html Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to listserv@java.sun.com
==================================================================== Companion Site: http://www.corej2eepatterns.com J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns List Archive: http://archives.java.sun.com/archives/j2eepatterns-interest.html Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to listserv@java.sun.com ______________________________________________________________________
This email message has been scanned by PineApp Mail-Secure and has been found clean.
==================================================================== Companion Site: http://www.corej2eepatterns.com J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns List Archive: http://archives.java.sun.com/archives/j2eepatterns-interest.html Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to listserv@java.sun.com
==================================================================== Companion Site: http://www.corej2eepatterns.com J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns List Archive: http://archives.java.sun.com/archives/j2eepatterns-interest.html Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to listserv@java.sun.com ______________________________________________________________________
This email message has been scanned by PineApp Mail-Secure and has been found clean.

==================================================================== Companion Site: http://www.corej2eepatterns.com J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns List Archive: http://archives.java.sun.com/archives/j2eepatterns-interest.html Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to listserv@java.sun.com

Re: Custom authentication strategy

Katz Guy

2004-02-18