Hi Tony,
Mmmm, kinda understand what you saying.... something like this, Tomcat wants
to check the users at the FRONT DOOR, and either kick them back onto the
street or let them in, but you want to let them ALL in and let some use the
dining room and some use the kitchen.... you trying to be polite and put a
NO ENTRY on the bathroom door before the user even tries. Interesting....
To trigger the built in Authentication you have to make the users all part
of a ComeInAndLookAround ROLE, but now everyone can get through any door, so
you need to check the additional roles yourself to determine access.... that
really defeats tomcats security, thus the problem.... I dont like this.
OR you need to leave the generic security alone, ie you have
Page1AccessRole, Page2AccessRole, so that normal humans can administer the
roles as Tomcat intended, and on each menu Item have
IsUserAllowedToAccessPageX, if not grey it, else show it. In this case you
would need to parse tomcat-users.xml which has the format like this <user
username="admin" password="" roles="admin,manager"/> and it not difficult to
find the roles for a user. Just some XML parsing.... I would go this way,
because its in the expertise of the Tomcat Admin guy or girl.
OR you could do the above but with your own internal logic, so you protect
access to pages with tomcat and then maybe have a separate file that lists
users and menu access allowed... in which case you need to make your own
config file, dB would work well..... could be the right way depending on
what you making.
OR you could decide FRONT DOOR checks are not for you.... and do it all
yourself, in which case this code will get you going....
Getting the user name and password
String authorization = request.getHeader("Authorization");
if (authorization == null) return 0;
// Authorization headers looks like "Basic blahblah",
// where blahblah is the base64 encoded username and
// password. We want the part after "Basic ".
String userInfo = authorization.substring(6).trim();
BASE64Decoder decoder = new BASE64Decoder();
String nameAndPassword = "";
try{
nameAndPassword = new
String(decoder.decodeBuffer(userInfo));
}catch ( IOException e ){}
// Decoded part looks like "username:password".
int index = nameAndPassword.indexOf(":");
String user = nameAndPassword.substring(0, index);
user = user.trim();
if(user == null) return 0;
String password = nameAndPassword.substring(index+1);
password = password.trim();
if(password == null) return 0;
To trigger the browser the headers look like this
response.setStatus(response.SC_UNAUTHORIZED);
response.setHeader("WWW-Authenticate", "BASIC
realm=\"User Check\"");
The coding is a hassel, but you have a lot of control.... like Ok You Not
Allowed In Here normally, but I'll let you in and grey all the menu's....
I'm not sure what it is you trying to do, hope this gets you going...
regards,
Johnny
----- Original Message -----
From: "Berglas, Anthony" <[EMAIL PROTECTED]>
To: <users@tomcat.apache.org>
Sent: Tuesday, March 27, 2007 2:22 AM
Subject: Basic Auth without web.xml <security-constraint> not working
Tomcat seems to only check the Authorization: headers if there is some
<security-constraint> explicitly declared in web.xml. However, it
appears that the optimization has been incorrectly implemented because
it does not then recheck the header if request.isUserInRole(...) etc.
are called. So users cannot log into a system that uses
request.isUserInRole(...).
More specifically,
my simple application tests request.isUserInRole(...) and
request.getRemoteUser(). If the user lacks permissions the application
sends a 401, and the user is prompted for a name/password which is sent
back as a Authorization: Basic dGltOlBhc3N3b3JkMQ==
So far so good. But Tomcat then ignores the Authorization: header which
is correctly sent by the browser.
The web.xml has
<login-config>
<auth-method>BASIC</auth-method>
<realm-name>Agile UI: tim/Password1</realm-name>
</login-config>
in it.
There is no <security-constraint> clause in the web.xml because I do not
want to declare them there. (They are instead declared internally as
part of a menuing system, which calls request.isUserInRole().)
A hack to make Tomcat look at the Authorization: header is to add the
following to web.xml
<security-constraint>
<web-resource-collection>
<web-resource-name>dbtest</web-resource-name>
<url-pattern>/dbtest/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>dummy<role-name>
</auth-constraint>
</security-constraint>
In which case it works if one accepts the unwanted dummy query.
Is it possible to tell Tomcat to always check the Authorization:?
Alternatively, is it possible to grant the dummy role to anonymous
users? Do anonymous users have any role that could be added to a dummy
<security-constraint>?
Is it possible for me to determine which users have which roles in my
application so that I can check the header myself? Ie. get at the
tomcat-users.xml style info, in a (fairly) web server independent
manner?
Or going the other way, is it possible for webapp to easily find out
what roles are required for a given .jsp to run? (We want to grey out
menu items that a user has no access to.)
My general feeling is that attempting to use Java Servlet security is
just wrong. One should simply do it oneself.
Anthony
--
Dr Anthony Berglas
Ph. +61 7 3227 4410
(Mob. +61 42 783 0248)
[EMAIL PROTECTED]; [EMAIL PROTECTED]
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
