RE: Basic Auth without web.xml security-constraint not working
Thanks for your replies, I think that the matter is settled. The underlying issue is that when Role R is required for Page P then *TWO* things need to happen depending on whether the user is in role R. These are 1. Allow or block access to page P. 2. Grey out or not grey out the menu item for page P. Right, I understand. The fact is that Tomcat will not perform authorization without also performing authentication. That is the crux of the matter. IMHO it is a bug, whether in the implementation or the spec I don't know or really care. The APIs take a very simplistic view of the world, and it just does not work for me at least. Pity, as not much more is needed. I could indeed scan web.xml given the inadequate API (rolesRequiredForUrl(), rolesForUser() etc.). (Scanning is possible but ugly -- needs duplication of URL pattern processing). But I prefer not to scan web.xml because I have other information about each form, and it would be nice to put the source of truth for the security info in the same place. But thanks for all the help. I have some Tomcat hacks that work for the time being. Later I will look for a fuller framework, either mine or someone else's, that is not J2EE based. If you really want to hack around with authentication and authorization, check out securityfilter (http://securityfilter.sourrceforge.net). The code is portable across servlet containers, and especially across different versions of the same container ;) Looks interesting. (Link is actually http://securityfilter.sourceforge.net, your link was to a spam site.) Anthony - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Basic Auth without web.xml security-constraint not working
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 All, Berglas, Anthony wrote: If you really want to hack around with authentication and authorization, check out securityfilter (http://securityfilter.sourrceforge.net). The code is portable across servlet containers, and especially across different versions of the same container ;) Looks interesting. (Link is actually http://securityfilter.sourceforge.net, your link was to a spam site.) Apologies for the typo. Spam sites totally suck :( - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGDIIF9CaO5/Lv0PARAiOLAJ9WRmG8MoLQBPtQtdLSbeMM53WcGgCgw2Da dfWPFRhwXD6VZ4maDcA1xTA= =vYSZ -END PGP SIGNATURE- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Basic Auth without web.xml security-constraint not working
Ha ha... sounds like you looking for a magic function, which reminds me of
my first computer program... got to tell you :)
A million years ago in my 1st year I was walking past the varsity main
frame, I'd heard all sorts of things about this amazing beast... so I walked
in, watched someone using a punch card, after they left, I typed draw
nude girl... stuck it in the machine and was hell-of-a-disappointed when I
got syntax error ha ha.
No, I think you expecting too much the Tomcat guys have let people who
want to develop a quick servlet, define the DOORWAY to the role in web.xml
and then quickly add users to the role in tomcat-users.xml and have
provided a few simple functions like isUserInRole, which for the simplest of
web sites are not even needed.
Its simple, easy, and probably good enough for most things a tomcat
developer needs... very nice of them.
I was hoping that for what you need it would be possible to piggyback on
that simple framework, even if it meant parsing the tomcat-users.xml to gray
menu's, but it seems you have to work outside of that frame-work.
If you are writing code like the stuff below forget about the simple
security framework tomcat provides, you dont need the Doorway in web.xml,
and likewise tomcat-users.xml is not going to do a thing it only wakes
up if you do the web.xml stuff. So if you define the URL and the restraining
role in web.xml, then tomcat wakes up and looks at tomcat-users.xml. If not,
it doesnt know you doing security, and even if you write security code, it
only between you and the browser, Tomcat will just send what you tell it to
and get a browser response back.
If you writing code at this level forget about that config stuff.
you on your own.
Cant quite see how you would use JAAS, but ok you going to use Ldap or
something.
No magic functions you have to do something like this...
Using your code below, you make a servlet, and map all the urls through it.
A request comes in
You grap the user name and password...
You call ldap or JAAS or whatever security system you using
It tells you User OK, or NOT
If OK you DISPATCH the request off to the JSP page and it displays.
If you want to control menu's you ask the LDAP system or whatever if user is
allowed access to various menu items (which represents other roles).
You stick that in a Bean pass it to the JSP page, it enables or disables
the menu's, and displays.
Not hard to do if you know tomcat
Somewhere and somehow you have to be able to tell the system all the users
and roles...
Whether you get it from JAAS or LDAP or parse the tomcat-users.xml,
somewhere someone has to be able to tell the system, USERA is in
RoleAccessPage1,23.
In fact I'm beginning to think that what you looking for is yet another
mapping...
So for example you may have a generic roles like, Visitors, Admin, Managers,
New Employees, Company Visitors blah blah...
And then have another XML file that says
ADMIN - ALL PAGES
VISTORS - Intro.jsp, Welcome.jsp,Instructions.jsp,How To Pay and access
the good stuff.jsp
I still have a feeling all you really need is the generic tomcat security
and someone to write a little XMLparsing code that gives you functions like
IsThisUserAllowedToAccesThisPage(User,Link);
Then you have Two Maps to fill out User - Role (already standard in
tomcat)
Role - Link (a
new XML file)
MaybeAnyway I dont think you going to find the magic function you
looking for, and I also dont think its an oversight by the tomcat
developers, just think you looking for an additional mapping function. Maybe
it would be nice if Tomcat had a function to enumerates user roles (has it?)
but even then you'd still be making some additional mapping function...
If you need someone to write the framework for you, once you have decided
what you want, call me.
Regards,
Johnny
- Original Message -
From: Berglas, Anthony [EMAIL PROTECTED]
To: Tomcat Users List users@tomcat.apache.org
Cc: [EMAIL PROTECTED]
Sent: Wednesday, March 28, 2007 3:26 AM
Subject: RE: Basic Auth without web.xml security-constraint not working
Thanks for your reply.
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
Re: Basic Auth without web.xml security-constraint not working
En l'instant précis du 27/03/07 02:22, Berglas, Anthony s'exprimait en ces termes: 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== Tomcat implements the J2EE security model, no more, no less. If you are developping web applications, you have 2 possibilities. Either you develop using this model (you limit access to ressources based on security-constraint), either you handle all the authentification stuff by yourself. What seems you want to be able to do is having a public part (with a menu which display items depending on eventual current user's role) and a private part accessible only to some roles. Fine, the J2EE model can handle it easily. All you have to do is 1) have your code be able to handle cases where there is no current user (aka anonymous) 2) Provide users with possibility to login via a simple url (eg. /webapp-name/login) which has a security constraint that make it accessible to any logged in user (just have a common role for all user, let's name it h 'user') Now when user have logged in and browse the public part, their Principal object is kept, they are still logged-in and you can check their role. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Basic Auth without web.xml security-constraint not working
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Anthony, Berglas, Anthony wrote: Thanks for the reply. The underlying issue is that when Role R is required for Page P then *TWO* things need to happen depending on whether the user is in role R. These are 1. Allow or block access to page P. 2. Grey out or not grey out the menu item for page P. Right, I understand. We only want to specify the fact that Role R is required for Page P ONCE. Declarations in web.xml handle 1. but not 2. This is because the servlet spec does not have any way to ask what roles will be required for another URI. In fact, there's no way to ask what what roles are required for the /current/ URI... you will have to determine the role requirements yourself, then loop over request.isUserInRole() checking each one looking for a match, then display the link as appropriate. It's messy, which is why not many people do this type of thing. Well, since you haven't asked Tomcat to provide authorization, it doesn't care about authentication. That seems perfectly reasonable to me. Not so. I have asked Tomcat to provide authorization by calling request.isUserInRole(...). And Tomcat fails. Calling request.isUserInRole does not turn on authorization checking. Adding security-constraint to web.xml does that. Tomcat is not failing. It is working as designed, and follows the servlet spec. If you can find another servlet container that /can/ do this, then it is operating outside of the servlet spec. IMHO it is a straight bug in an optimization. isUserInRole etc. needs to have an extra test: if (! authenticationHeaderProcessed() ) processAuthenticationHeader(); Request.isUserInRole should happen long after the headers are processed. Your user's role it set at authentication time, not determined at authorization time. Honestly, your best bet IMO is to scan web.xml yourself at webapp startup and build your own list of URIs and role mappings. Then, you can consult your own registry to find out whether the current user will be allowed to access a particular URI. Actually, it doesn't sound that hard. The only problem is that you will have to step outside of the API provided by the servlet spec (which is not a big deal at all). The fact is that Tomcat will not perform authorization without also performing authentication. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGCmvy9CaO5/Lv0PARAgpEAKCY+BbJMeEdVSD/0D8F3arcDrlMGwCePcIM IQPleQoqiV4hDIzTDW/tTMs= =AxRG -END PGP SIGNATURE- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Basic Auth without web.xml security-constraint not working
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Johnny, I was hoping that for what you need it would be possible to piggyback on that simple framework, even if it meant parsing the tomcat-users.xml to gray menu's, but it seems you have to work outside of that frame-work. Parsing tomcat-users.xml never makes any sense. You can get all the information provided from that file through the servlet API: the user's name (request.getUserPrincipal().getName()) and you can check the roles using request.isUserInRole() -- of course, you have to know what roles to check, but you should already know that. What you might want to parse is the authorization mapping, which usually resides in web.xml. The OP wants to put this somewhere else (not sure why) and then have Tomcat enforce it (which ain't gonna happen). If you writing code at this level forget about that config stuff. you on your own. If you really want to hack around with authentication and authorization, check out securityfilter (http://securityfilter.sourrceforge.net). The code is portable across servlet containers, and especially across different versions of the same container ;) I still have a feeling all you really need is the generic tomcat security and someone to write a little XMLparsing code that gives you functions like IsThisUserAllowedToAccesThisPage(User,Link); I believe this is correct. Then you have Two Maps to fill out User - Role (already standard in tomcat) There's no reason to manage that map yourself. All you need is what's already in the servlet API. You can also get the Role - Link (really, URIs mapped to allowed roles) from web.xml. Just parse web.xml looking for security-constraint elements and use those. One single point of configuration (a requirement by the OP), and Tomcat enforces your authorization, which is a nice feature. Not having to write your own security code is always nice, because usually other people's (security) code is better than yours is likely to be. MaybeAnyway I dont think you going to find the magic function you looking for The only thing I can think of us using JMX to snoop Tomcat's existing URI-Roles mapping, which is't got to have lying around. The only question is whether or not it is available to unprivileged webapps. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGCm5t9CaO5/Lv0PARAmDDAKCnMJBeiVYkIro2mNh5xs+tfcjWQgCeL/hS 5MEhE/C7B3ArZfB2ktsoZs4= =TfAo -END PGP SIGNATURE- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Basic Auth without web.xml security-constraint not working
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-methodBASIC/auth-method
realm-nameAgile 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-namedbtest/web-resource-name
url-pattern/dbtest/*/url-pattern
/web-resource-collection
auth-constraint
role-namedummyrole-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
Re: Basic Auth without web.xml security-constraint not working
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Anthony,
Berglas, Anthony wrote:
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(...).
Well, since you haven't asked Tomcat to provide authorization, it
doesn't care about authentication. That seems perfectly reasonable to me.
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==
I'm guessing that you are manually sending the HTTP Auth header, right?
If that's the case, then you'll have to manually process the HTTP Auth
header coming from the client.
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().)
Any reason not to use the built-in authorization features of the servlet
spec (which Tomcat correctly implements, IMO)?
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.)
Usually, this is done using a manual process where you call
request.isUserInRole('whatever') and then choose to display or not
display the links as appropriate. I don't believe there is a facility
for asking about what role /will be required/ for a certain URI pattern.
My general feeling is that attempting to use Java Servlet security is
just wrong. One should simply do it oneself.
Using Java security is super simple. Why are you complicating things?
I'm sure there's a good reason. I'd just like to hear it.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGCISx9CaO5/Lv0PARAv3eAJ9nC55oyOhFr0XdBWC87+hyBvrHqgCfTRSh
R7Nq3QMh0JbgddAkimpJZY0=
=9t1T
-END PGP SIGNATURE-
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
