Re: Programmatic security with servlet mappings in tomcat

2001-07-03 Thread anil

You can setup a custom login screen and set it up in the tomcat. I am doing
it. and you can access the username and password from session variables
j_username and j_password. also you can access requested link from session.

 
FORM

  /LogIn
 /LogIn
  
 

I like the tomcat login module because it is transparent. I guess you check
the role, roleGroup and set response.sendError(401,..) to redirect user back
to login page if he/she does not have enough previlages.

did I miss anything here??

anil


pete wrote:

> Sure, one is that i want custom login screens, another is that we store
> all our authentication details centrally and query for them via an XML
> data service.
>
> Various user and domain-specific data, including user preferences,roles
> etc. is stored in this repository, not just 'yes, this user has blanket
> access to the site'.
>
> Our permissions-management tools are all written to work with this, so i
> have an existing system i must fit my tomcat-based solutions into here.
>
> I do use tomcat's basic authentication facilities for some unrelated
> services, but for us it makes a lot of sense to centralize
> authentication and preference data this way.
>




Re: Programmatic security with servlet mappings in tomcat

2001-07-03 Thread Antony Bowesman

pete wrote:
> 
> Sure, one is that i want custom login screens, another is that
> we store all our authentication details centrally and query for
> them via an XML data service.
> 
> Various user and domain-specific data, including user preferences,
> roles etc. is stored in this repository, not just 'yes, this user
> has blanket access to the site'.

You mean custom login screens per JSP?  We had the same issue about how
to protect the site and eventually went for getting the container to
handle the security.  Now we have optionally different login screens for
different webapps and a tomcat realm that authenticates users against a
user repository running in an EJB container.  Permissions are then
checked using JAAS and realm loads groups,roles etc from the user realm
into the JAAS context.

In addition J2EE roles are also mapped from roles in the user realm so
we can use J2EE security and roles are dynamic rather than having to
redeploy apps.

We opted against the JSP approach because it means that the onus was on
the developer to think about security :))  At least from the
presentation point of view, but for the business logic there has to be
some thought...

Antony

> Our permissions-management tools are all written to work with this,
> so i have an existing system i must fit my tomcat-based solutions
> into here.
> 
> I do use tomcat's basic authentication facilities for some unrelated
> services, but for us it makes a lot of sense to centralize
> authentication and preference data this way.
> 
> If someone writes an app that doesn't protect the page? well, then
> the page is unprotected.
> 
> Security never comes completely for 'free', and in my experience
> it is beneficial to place some onus on the developer to at least
> think about security during the course of development.
> 
> YMMV, of course, but this approach has worked well for us.
> 
> -Pete
> 
> > Pete,
> >
> >
> > Interesting that you don't use the container's authentication mechanism
> > to protect pages.  What if someone writes an app that doesn't protect
> > the page.  Any reason why you chose this route?
> >
> > Rgds
> > Antony



Re: Programmatic security with servlet mappings in tomcat

2001-07-03 Thread pete

Sure, one is that i want custom login screens, another is that we store 
all our authentication details centrally and query for them via an XML 
data service.

Various user and domain-specific data, including user preferences,roles 
etc. is stored in this repository, not just 'yes, this user has blanket 
access to the site'.

Our permissions-management tools are all written to work with this, so i 
have an existing system i must fit my tomcat-based solutions into here.

I do use tomcat's basic authentication facilities for some unrelated 
services, but for us it makes a lot of sense to centralize 
authentication and preference data this way.

If someone writes an app that doesn't protect the page? well, then the 
page is unprotected.

Security never comes completely for 'free', and in my experience it is 
beneficial to place some onus on the developer to at least think about 
security during the course of development.

YMMV, of course, but this approach has worked well for us.

-Pete

> Pete,
> 
> 
> Interesting that you don't use the container's authentication mechanism
> to protect pages.  What if someone writes an app that doesn't protect
> the page.  Any reason why you chose this route?
> 
> Rgds
> Antony






RE: Programmatic security with servlet mappings in tomcat

2001-07-03 Thread


I wrote my own custom authentication scheme for exactly the same reasons.  I
hope Tomcat will soon add forms based authentication so I can remove this
(unnecessary) level of complexity from my applications.




Emir.

-Original Message-
From: Hughes, Tim [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 03, 2001 12:50 PM
To: '[EMAIL PROTECTED]'
Subject: RE: Programmatic security with servlet mappings in tomcat



I did not want to use the container's authentication mechanism for several
reasons:

1. I can't store passwords and usernames in a database.
2. I get more control over the login process e.g. I can give different login
error message depending on the source of the login failiure (wrong password,
wrong username, etc ...) + I can log these login failiures (useful since
they may help in detecting "breakins").
3. I read in Wrox Professional Java Server Programming that "as of writing
this chapter, Tomcat (Version 3.1) does not completely support form-based
authentication. Although Tomcat includes an experimentation version of
form-based authentication, this is not suitable for demonstration purposes".


~~~
Tim Hughes
~~



-Original Message-
From: Antony Bowesman [mailto:[EMAIL PROTECTED]]
Sent: 3. juli 2001 10:32
To: [EMAIL PROTECTED]
Subject: Re: Programmatic security with servlet mappings in tomcat


Pete,

pete wrote:
> 
> Tim,
> 
> there are several ways to implement this kind of security check. If you
> want a fullblown MVC model, you might consider looking at Struts or one
> of the other Apache-driven frameworks (Struts is the only one i have
> personal experience with).
> 
> with the example you give, i don't understand the need for a
> 'controller' jsp in this context.
> 
> The way i handle security in one of my apps is that i have a method in a
> session-bean (public void isAuthenticated()) that checks the user has a
> valid login, so all my jsps (except login.jsp) are wrapped in a
> statement like
> 
>  class="com.mycompany.authentication">
> 
> <%if (Authentication.isAuthenticated())
> {%>
> 
>  rest of JSP goes here
> 
> <%}
> else
> {
> response.sendRedirect("./login.jsp");
> }
> %>
> 
> If a valid session key is already assigned, the method returns true. If
> username and password are supplied in request scope, isAuthenticated
> does a lookup to our authentication database, and if successful, sets a
> valid session key, and returns true.
> 
> If neither of these are true, isAuthenticated sets a 'you are not
> authenticated' message to be displayed by login.jsp,  returns false, and
> the user is redirected back to login.jsp

Interesting that you don't use the container's authentication mechanism
to protect pages.  What if someone writes an app that doesn't protect
the page.  Any reason why you chose this route?

Rgds
Antony


This message contains information that may be privileged or confidential and
is the property of the Cap Gemini Ernst & Young Group. It is intended only
for the person to whom it is addressed. If you are not the intended
recipient, you are not authorized to read, print, retain, copy, disseminate,
distribute, or use this message or any part thereof. If you receive this
message in error, please notify the sender immediately and delete all copies
of this message.



Re: Programmatic security with servlet mappings in tomcat

2001-07-03 Thread Antony Bowesman

Pete,

pete wrote:
> 
> Tim,
> 
> there are several ways to implement this kind of security check. If you
> want a fullblown MVC model, you might consider looking at Struts or one
> of the other Apache-driven frameworks (Struts is the only one i have
> personal experience with).
> 
> with the example you give, i don't understand the need for a
> 'controller' jsp in this context.
> 
> The way i handle security in one of my apps is that i have a method in a
> session-bean (public void isAuthenticated()) that checks the user has a
> valid login, so all my jsps (except login.jsp) are wrapped in a
> statement like
> 
>  class="com.mycompany.authentication">
> 
> <%if (Authentication.isAuthenticated())
> {%>
> 
>  rest of JSP goes here
> 
> <%}
> else
> {
> response.sendRedirect("./login.jsp");
> }
> %>
> 
> If a valid session key is already assigned, the method returns true. If
> username and password are supplied in request scope, isAuthenticated
> does a lookup to our authentication database, and if successful, sets a
> valid session key, and returns true.
> 
> If neither of these are true, isAuthenticated sets a 'you are not
> authenticated' message to be displayed by login.jsp,  returns false, and
> the user is redirected back to login.jsp

Interesting that you don't use the container's authentication mechanism
to protect pages.  What if someone writes an app that doesn't protect
the page.  Any reason why you chose this route?

Rgds
Antony



RE: Programmatic security with servlet mappings in tomcat

2001-07-03 Thread Hughes, Tim


Hi,

Thanks for the help.

Your suggestion is one way of implementing the security. The reason I
suggest a controller as the first page that all requests must go through is
that I was hoping that it would enable me to factor out the authentification
check that you have on every page i.e. instead of having the 




<%if (Authentication.isAuthenticated())
{%>

 rest of JSP goes here

<%}
else
{
response.sendRedirect("./login.jsp");
}
%>

on every page, I could have a controller that looked like:

if (requesting login)
{

// forward to handleLogin.jsp

}
else
{
if (not logged on)
{
//forward to submitLoginInfo.jsp
}
else
{
//forward to appropriate servicing JSP
//(which I can determine from the URL or by having an
"action" parameter in the request)
}

}

If I want to implement this I need to be sure that it is not possible to get
access to the servicing JSPs "directly" since they wouldn't have any
security embedded in them.

What do you reckon?

~~
Tim Hughes
~



-Original Message-
From: pete [mailto:[EMAIL PROTECTED]]
Sent: 3. juli 2001 01:00
To: [EMAIL PROTECTED]
Subject: Re: Programmatic security with servlet mappings in tomcat


Tim,

there are several ways to implement this kind of security check. If you 
want a fullblown MVC model, you might consider looking at Struts or one 
of the other Apache-driven frameworks (Struts is the only one i have 
personal experience with).

with the example you give, i don't understand the need for a 
'controller' jsp in this context.

The way i handle security in one of my apps is that i have a method in a 
session-bean (public void isAuthenticated()) that checks the user has a 
valid login, so all my jsps (except login.jsp) are wrapped in a 
statement like




<%if (Authentication.isAuthenticated())
{%>

 rest of JSP goes here

<%}
else
{
response.sendRedirect("./login.jsp");
}
%>

If a valid session key is already assigned, the method returns true. If 
username and password are supplied in request scope, isAuthenticated 
does a lookup to our authentication database, and if successful, sets a 
valid session key, and returns true.

If neither of these are true, isAuthenticated sets a 'you are not 
authenticated' message to be displayed by login.jsp,  returns false, and 
the user is redirected back to login.jsp

In our struts projects, we have a custom tag library that checks 
authentication details, so its even simpler than the above.

This example lacks exhaustive detail, but it is pretty easy to implement 
a security model like this. There are a number of foibles you can make, 
however. I'd tell you what they are, but that would spoil your fun now, 
wouldn't it ;)

Hope that helps

-Pete




> Hi,
> 
> (Tomcat 3.2.1, windows 2000, JdK1.3.1)
> 
> I want to use a Request Controller architecture for a webapp (i.e. one JSP
> that receives all requests and then dispatches the requests to other JSPs
> for servicing of the request). Of course I want to ensure that these
> "servicing" JSPs are not accessible without passing through the controller
> jsp. Is a secure solution to this problem to use a servlet mapping of the
> following form in web.xml:
> 
> 
> 
> 
> controller
> controller.jsp
> 
> 
> 
> 
> controller
> /*
> 
> 
> 
> 
> 
> And to include in Controller.jsp a session bean for each user to check
> whether they have logged on to the site before forwarding their request to
> the "servicing" JSP.
> 
> I have tried this out "empirically" myself and it seems to work but I
would
> quite like a "theoretical" confirmation that this is secure and that this
> solution makes it impossible for a malicious user to get access to the
> "servicing" JSPs (without passing through Controller.jsp which will force
a
> logon).
> 
> Thanks.
> 
> Tim.
> 
> 
> This message contains information that may be privileged or confidential
and is the property of the Cap Gemini Ernst & Young Group. It is intended
only for the person to whom it is addressed. If you are not the intended
recipient, you are not authorized to read, print, retain, copy, disseminate,
distribute, or use this message or any part thereof. If you receive this
message in error, please notify the sender immediately and delete all copies
of this message.




This message contains information that may be privileged or confidential and is the 
property of the Cap Gemini Ernst & Young Group. It is intended only for the person to 
whom it is addressed. If you are not the intended recipient, you are not authorized to 
read, print, retain, copy, disseminate, distribute, or use this message or any part 
thereof. If you receive this message in error, please notify the sender immediately 
and delete all copies of this message.



Re: Programmatic security with servlet mappings in tomcat

2001-07-02 Thread pete

Tim,

there are several ways to implement this kind of security check. If you 
want a fullblown MVC model, you might consider looking at Struts or one 
of the other Apache-driven frameworks (Struts is the only one i have 
personal experience with).

with the example you give, i don't understand the need for a 
'controller' jsp in this context.

The way i handle security in one of my apps is that i have a method in a 
session-bean (public void isAuthenticated()) that checks the user has a 
valid login, so all my jsps (except login.jsp) are wrapped in a 
statement like




<%if (Authentication.isAuthenticated())
{%>

 rest of JSP goes here

<%}
else
{
response.sendRedirect("./login.jsp");
}
%>

If a valid session key is already assigned, the method returns true. If 
username and password are supplied in request scope, isAuthenticated 
does a lookup to our authentication database, and if successful, sets a 
valid session key, and returns true.

If neither of these are true, isAuthenticated sets a 'you are not 
authenticated' message to be displayed by login.jsp,  returns false, and 
the user is redirected back to login.jsp

In our struts projects, we have a custom tag library that checks 
authentication details, so its even simpler than the above.

This example lacks exhaustive detail, but it is pretty easy to implement 
a security model like this. There are a number of foibles you can make, 
however. I'd tell you what they are, but that would spoil your fun now, 
wouldn't it ;)

Hope that helps

-Pete




> Hi,
> 
> (Tomcat 3.2.1, windows 2000, JdK1.3.1)
> 
> I want to use a Request Controller architecture for a webapp (i.e. one JSP
> that receives all requests and then dispatches the requests to other JSPs
> for servicing of the request). Of course I want to ensure that these
> "servicing" JSPs are not accessible without passing through the controller
> jsp. Is a secure solution to this problem to use a servlet mapping of the
> following form in web.xml:
> 
> 
> 
> 
> controller
> controller.jsp
> 
> 
> 
> 
> controller
> /*
> 
> 
> 
> 
> 
> And to include in Controller.jsp a session bean for each user to check
> whether they have logged on to the site before forwarding their request to
> the "servicing" JSP.
> 
> I have tried this out "empirically" myself and it seems to work but I would
> quite like a "theoretical" confirmation that this is secure and that this
> solution makes it impossible for a malicious user to get access to the
> "servicing" JSPs (without passing through Controller.jsp which will force a
> logon).
> 
> Thanks.
> 
> Tim.
> 
> 
> This message contains information that may be privileged or confidential and is the 
>property of the Cap Gemini Ernst & Young Group. It is intended only for the person to 
>whom it is addressed. If you are not the intended recipient, you are not authorized 
>to read, print, retain, copy, disseminate, distribute, or use this message or any 
>part thereof. If you receive this message in error, please notify the sender 
>immediately and delete all copies of this message.






RE: Programmatic security with servlet mappings in tomcat

2001-07-02 Thread Hughes, Tim


Hi,

(Tomcat 3.2.1, windows 2000, JdK1.3.1)

I want to use a Request Controller architecture for a webapp (i.e. one JSP
that receives all requests and then dispatches the requests to other JSPs
for servicing of the request). Of course I want to ensure that these
"servicing" JSPs are not accessible without passing through the controller
jsp. Is a secure solution to this problem to use a servlet mapping of the
following form in web.xml:




controller
controller.jsp




controller
/*





And to include in Controller.jsp a session bean for each user to check
whether they have logged on to the site before forwarding their request to
the "servicing" JSP.

I have tried this out "empirically" myself and it seems to work but I would
quite like a "theoretical" confirmation that this is secure and that this
solution makes it impossible for a malicious user to get access to the
"servicing" JSPs (without passing through Controller.jsp which will force a
logon).

Thanks.

Tim.


This message contains information that may be privileged or confidential and is the 
property of the Cap Gemini Ernst & Young Group. It is intended only for the person to 
whom it is addressed. If you are not the intended recipient, you are not authorized to 
read, print, retain, copy, disseminate, distribute, or use this message or any part 
thereof. If you receive this message in error, please notify the sender immediately 
and delete all copies of this message.



RE: Programmatic security with servlet mappings in tomcat

2001-07-02 Thread Hughes, Tim

Hi,

(Tomcat 3.2.1, windows 2000, JdK1.3.1)

I want to use a Request Controller architecture for a webapp (i.e. one JSP
that receives all requests and then dispatches the requests to other JSPs
for servicing of the request). Of course I want to ensure that these
"servicing" JSPs are not accessible without passing through the controller
jsp. Is a secure solution to this problem to use a servlet mapping of the
following form in web.xml:




controller
controller.jsp




controller
/*





And to include in Controller.jsp a session bean for each user to check
whether they have logged on to the site before forwarding their request to
the "servicing" JSP.

I have tried this out "empirically" myself and it seems to work but I would
quite like a "theoretical" confirmation that this is secure and that this
solution makes is impossible for a malicious user to get access to the
"servicing" JSPs (without passing through Controller.jsp which will force a
logon).

Thanks.

Tim.



This message contains information that may be privileged or confidential and is the 
property of the Cap Gemini Ernst & Young Group. It is intended only for the person to 
whom it is addressed. If you are not the intended recipient, you are not authorized to 
read, print, retain, copy, disseminate, distribute, or use this message or any part 
thereof. If you receive this message in error, please notify the sender immediately 
and delete all copies of this message.