Re: Custom realm.authenticate() that would work with any realm - possible?
Hi, I'm sure that the response can't be so simple. Surely my English don't allows me understand the cuestion. I don't know why you want do it, but if you want realy to do an login without password, you can use Jaas. It's a bit complicated explain it here, but if you be able to read Spanish you can try here http://finger-in-the-eye.blogspot.com/2011/09/modulo-de-login-personalizado-para.html?m=1 Bye El 09/12/2011 04:19, oh...@cox.net escribió: Hi, This is a followup to an earlier thread, Do any of the Tomcat LDAP-type realms support no password authentication?. As I mentioned in that earlier thread, I'm still new to Tomcat, and still trying to find my way around, and understand (somewhat) its security design, so apologies in advance if my terminology is incorrect. Ok. I've been experimenting with writing what I think is called a custom realm, that would have a no password authenticate() method. What I think that I've been able to do is to implement a new realm where all I do in my code is override the uthenticate(Context, string, string) method. For my initial attempt, I'm just extending the JNDIRealm, and just overriding that one method, and I think that this works. However, ideally, I really want to be able to do this (override the authenticate() method with any of the default realms that come with Tomcat, whereas with the approach that I'm currently working (extending the JNDIRealm), in order to do this for all the different realm types, I'd have to implement something similar, with a custom realm corresponding to each of the out-of-box Tomcat realm types. That might be ok, but I was wondering if there might, perhaps, be another way to do what I'm trying to do (basically have an realm.authenticate() method that doesn't require a password, but that would work with any realm? Thanks, Jim - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Custom realm.authenticate() that would work with any realm - possible?
oh...@cox.net wrote:
André Warnier a...@ice-sa.com wrote:
oh...@cox.net wrote:
André Warnier a...@ice-sa.com wrote:
Hi Jim.
As I recall, your original issue was that there is no OAM plugin for Tomcat, and
therefore, you are doing the OAM authentication within the front-end Apache, and then
passing the user-id to Tomcat.
And then, you find yourself in Tomcat with a user-id, but without any roles
corresponding to this user-id.
And in order to get such roles, you are now facing a rather complex programming issue at
the Tomcat level.
I wrote this before, but let me repeat it : are you not doing a lot of work un-necessarily
there, and should you not look at this another way ?
As far as I understand these Tomcat-level matters, a role in Tomcat is used to control
access to resources.
And you seem to use Tomcat's declarative type of acess-control, which means that you
allow access or not to a given webapp, in function of whether the user-id (which is passed
to Tomcat by the front-end) has or not a particular role.
And, in the OAM system globally, the fact that a user has or not access to a particular
resource, is already managed at the OAM level; but to which OAM level, unfortunately right
now, you do not have access from Tomcat.
But in this case, all your accesses to Tomcat webapps *always* happen through the
front-end, because it is this front-end which obtains the user-id (from OAM) and later
passes it to Tomcat. And this front-end thus *has* access to the OAM data.
So what is stopping you from :
- not using any authentication/access-control at the Tomcat level
- but checking all this at the Apache httpd front-end level
?
Example : suppose you have 3 webapps app1, app2, app3.
You could have at the front-end level these sections :
Location /app1
SetHandler jakarta-servlet (same as JkMount /app1)
AuthType Oblix
require valid-user
require .. (whatever)
/Location
Location /app2
SetHandler jakarta-servlet (same as JkMount /app2)
AuthType Oblix
require valid-user
require .. (whatever)
/Location
Location /app3
SetHandler jakarta-servlet (same as JkMount /app3)
AuthType Oblix
require valid-user
require .. (whatever)
/Location
If the user does not pass muster for /app1 according to OAM, then the call will never
even make it Tomcat.
If the user passes muster, then you can let them access Tomcat's /app1 application, as
they have been checked for it.
Or am I missing something ?
Hi,
Yes, you are missing something, something akin to the last mile.
Following your example, of /app1, suppose that that is a webapp that requires a known
user (principal). The security JSP example in Tomcat is an example of this.
You can use something like OAM to protect (permit or deny) access, but once you get to the /app1, you wouldn't be
logged into the app itself, not only for declarative type constraints, but also, for example, if the app
does things like give you access to only specified resources (e.g., database tables, etc.) based on who you
are. So, for example with the security example, with just OAM, and without anything else, you end up
on the form login page, instead of it saying Hi, x.
Just some examples there...
Ok, I may be misunderstanding the scope of OAM within your organisation, maybe because I
am going by the OAM documentation as I was browsingt it on the web.
If you are using it only as an SSO system and only to get a user-id, then your example is
correct.
From the documentation, it just sounded like it is much more than that.
What I was trying to say is more or less this : if all accesses to your Tomcat
applications necessarily go through the front-end, then for all intents and purposes the
front-end and Tomcat are functionally one and the same system. Or, to put it another way,
you could consider the front-end as just a part of Tomcat; or again to put it yet another
way, your front-end /is/ your Tomcat authentication realm.
And whatever information you can obtain at the front-end level, you can pass to Tomcat as
request attributes, which attributes you can retrieve in Tomat and pass to your
applications, for them to use to make any access decision they want.
Hi Andre,
The thing is, as you yourself mentioned earlier, some (maybe a lot) of systems
(apps), utilize declarative security constraints (e.g., in web.xml), in order
to avoid having to put code in the app that does stuff like (this is just
pseudo-code):
if (user.isInRole(xyz) {
.
That would be rather bad, wouldn't it ? (from a maintainability and management
perspective)
.
}
If the app/webapp utilizes declarative security (constraints, etc.), then just
protecting the app's URIs at the Apache isn't sufficient.
I'm not wanting to get in to a debate about the pros/cons of declarative vs.
programmatic.
neither am I.
The area that I'm in (my job) is just to provide, rather than dictate, the capabilities
that the various apps need,
So
RE: Custom realm.authenticate() that would work with any realm - possible?
Hi Chuck, Thanks for the pointer to the CombinedRealm, but, as I've been working with the test implementation that I mentioned for extending the JNDIRealm, I *think* that I'm coming to the realization that I was asking for is probably not possible, or at least not practical, unless I'm totally missing something. The reason I'm thinking this is that, for example, in the case where I'm extending the JNDIRealm, in my custom JNDIRealm, I've had to make calls to the super.set() methods to set parameters in the JNDIRealm class that I'm extending, in order for the calls that I then make to the super class (e.g., super.getUser()) to work. Again, I may be missing something, or doing things completely wrong, but if not, then that means that if I was going to try go design my realm extender to support all of the normal realm types, my code would get fairly complex, because it'd have to know all of the parameters for all of the different realm types, in order to set the parameters in the super class. It was messy enough doing that for just one realm type (JNDIRealm), and for just calling two methods in the super JNDIRealm class, but I imagine if I was trying to extend 5 or 6 realm types, all in one piece of code, it'd be a real mess. Anyway, if anyone has some insight into doing something like this, please post back. Otherwise, I think the best approach is to implement one realm extension for each of the normal Tomcat realms that we'll want to be able to support. Thanks again, Jim Caldarale wrote: From: oh...@cox.net [mailto:oh...@cox.net] Subject: Custom realm.authenticate() that would work with any realm - possible? I was wondering if there might, perhaps, be another way to do what I'm trying to do (basically have an realm.authenticate() method that doesn't require a password, but that would work with any realm? Look at the CombinedRealm; you might be able to use your no-password realm in conjunction with one of the others, since the doc says Authentication against any Realm will be sufficient to authenticate the user. I don't know if that will get you the necessary roles established. http://tomcat.apache.org/tomcat-7.0-doc/realm-howto.html#CombinedRealm - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Custom realm.authenticate() that would work with any realm - possible?
On 09/12/11 18:02, oh...@cox.net wrote: Hi Chuck, Thanks for the pointer to the CombinedRealm, but, as I've been working with the test implementation that I mentioned for extending the JNDIRealm, I *think* that I'm coming to the realization that I was asking for is probably not possible, or at least not practical, unless I'm totally missing something. The reason I'm thinking this is that, for example, in the case where I'm extending the JNDIRealm, in my custom JNDIRealm, I've had to make calls to the super.set() methods to set parameters in the JNDIRealm class that I'm extending, in order for the calls that I then make to the super class (e.g., super.getUser()) to work. Again, I may be missing something, or doing things completely wrong, but if not, then that means that if I was going to try go design my realm extender to support all of the normal realm types, my code would get fairly complex, because it'd have to know all of the parameters for all of the different realm types, in order to set the parameters in the super class. It was messy enough doing that for just one realm type (JNDIRealm), and for just calling two methods in the super JNDIRealm class, but I imagine if I was trying to extend 5 or 6 realm types, all in one piece of code, it'd be a real mess. Anyway, if anyone has some insight into doing something like this, please post back. Otherwise, I think the best approach is to implement one realm extension for each of the normal Tomcat realms that we'll want to be able to support. Thanks again, Jim I have come to this thread rather late in the day and I don't want to confuse the situation... take my comment, if it is relevant, with caution. If it isn't relevant, don't let me spiral it off-topic. The servlet 3.0 spec allows for vendor specific Login-config auth-method values, e.g. tomcat uses NONE for containers that have not defined a login-config section. The standard login methods (FORM, BASIC, etc) are implemented as concrete classes that extend org.apache.catalina.authenticator.AuthenticatorBase (e.g. FormAuthenticator, BasicAuthenticator, etc). Have you considered writing a vendor specific NoPasswordAuthenticator class to do what you need? It needs to contain little more than an authenticate method that will be called by all appropriate code. I have just submitted a suggested fix to NonLoginAuthenticator (https://issues.apache.org/bugzilla/show_bug.cgi?id=52303) which shows how to inject an existing Principal instance into a SingleSignOn session. This might give you some idea how to achieve what you want without the complexity of subclassing all the standard realms. Regards, Brian - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Custom realm.authenticate() that would work with any realm - possible?
Hi Jim. As I recall, your original issue was that there is no OAM plugin for Tomcat, and therefore, you are doing the OAM authentication within the front-end Apache, and then passing the user-id to Tomcat. And then, you find yourself in Tomcat with a user-id, but without any roles corresponding to this user-id. And in order to get such roles, you are now facing a rather complex programming issue at the Tomcat level. I wrote this before, but let me repeat it : are you not doing a lot of work un-necessarily there, and should you not look at this another way ? As far as I understand these Tomcat-level matters, a role in Tomcat is used to control access to resources. And you seem to use Tomcat's declarative type of acess-control, which means that you allow access or not to a given webapp, in function of whether the user-id (which is passed to Tomcat by the front-end) has or not a particular role. And, in the OAM system globally, the fact that a user has or not access to a particular resource, is already managed at the OAM level; but to which OAM level, unfortunately right now, you do not have access from Tomcat. But in this case, all your accesses to Tomcat webapps *always* happen through the front-end, because it is this front-end which obtains the user-id (from OAM) and later passes it to Tomcat. And this front-end thus *has* access to the OAM data. So what is stopping you from : - not using any authentication/access-control at the Tomcat level - but checking all this at the Apache httpd front-end level ? Example : suppose you have 3 webapps app1, app2, app3. You could have at the front-end level these sections : Location /app1 SetHandler jakarta-servlet (same as JkMount /app1) AuthType Oblix require valid-user require .. (whatever) /Location Location /app2 SetHandler jakarta-servlet (same as JkMount /app2) AuthType Oblix require valid-user require .. (whatever) /Location Location /app3 SetHandler jakarta-servlet (same as JkMount /app3) AuthType Oblix require valid-user require .. (whatever) /Location If the user does not pass muster for /app1 according to OAM, then the call will never even make it Tomcat. If the user passes muster, then you can let them access Tomcat's /app1 application, as they have been checked for it. Or am I missing something ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Custom realm.authenticate() that would work with any realm - possible?
André Warnier a...@ice-sa.com wrote: Hi Jim. As I recall, your original issue was that there is no OAM plugin for Tomcat, and therefore, you are doing the OAM authentication within the front-end Apache, and then passing the user-id to Tomcat. And then, you find yourself in Tomcat with a user-id, but without any roles corresponding to this user-id. And in order to get such roles, you are now facing a rather complex programming issue at the Tomcat level. I wrote this before, but let me repeat it : are you not doing a lot of work un-necessarily there, and should you not look at this another way ? As far as I understand these Tomcat-level matters, a role in Tomcat is used to control access to resources. And you seem to use Tomcat's declarative type of acess-control, which means that you allow access or not to a given webapp, in function of whether the user-id (which is passed to Tomcat by the front-end) has or not a particular role. And, in the OAM system globally, the fact that a user has or not access to a particular resource, is already managed at the OAM level; but to which OAM level, unfortunately right now, you do not have access from Tomcat. But in this case, all your accesses to Tomcat webapps *always* happen through the front-end, because it is this front-end which obtains the user-id (from OAM) and later passes it to Tomcat. And this front-end thus *has* access to the OAM data. So what is stopping you from : - not using any authentication/access-control at the Tomcat level - but checking all this at the Apache httpd front-end level ? Example : suppose you have 3 webapps app1, app2, app3. You could have at the front-end level these sections : Location /app1 SetHandler jakarta-servlet (same as JkMount /app1) AuthType Oblix require valid-user require .. (whatever) /Location Location /app2 SetHandler jakarta-servlet (same as JkMount /app2) AuthType Oblix require valid-user require .. (whatever) /Location Location /app3 SetHandler jakarta-servlet (same as JkMount /app3) AuthType Oblix require valid-user require .. (whatever) /Location If the user does not pass muster for /app1 according to OAM, then the call will never even make it Tomcat. If the user passes muster, then you can let them access Tomcat's /app1 application, as they have been checked for it. Or am I missing something ? Hi, Yes, you are missing something, something akin to the last mile. Following your example, of /app1, suppose that that is a webapp that requires a known user (principal). The security JSP example in Tomcat is an example of this. You can use something like OAM to protect (permit or deny) access, but once you get to the /app1, you wouldn't be logged into the app itself, not only for declarative type constraints, but also, for example, if the app does things like give you access to only specified resources (e.g., database tables, etc.) based on who you are. So, for example with the security example, with just OAM, and without anything else, you end up on the form login page, instead of it saying Hi, x. Just some examples there... Jim - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Custom realm.authenticate() that would work with any realm - possible?
oh...@cox.net wrote: André Warnier a...@ice-sa.com wrote: Hi Jim. As I recall, your original issue was that there is no OAM plugin for Tomcat, and therefore, you are doing the OAM authentication within the front-end Apache, and then passing the user-id to Tomcat. And then, you find yourself in Tomcat with a user-id, but without any roles corresponding to this user-id. And in order to get such roles, you are now facing a rather complex programming issue at the Tomcat level. I wrote this before, but let me repeat it : are you not doing a lot of work un-necessarily there, and should you not look at this another way ? As far as I understand these Tomcat-level matters, a role in Tomcat is used to control access to resources. And you seem to use Tomcat's declarative type of acess-control, which means that you allow access or not to a given webapp, in function of whether the user-id (which is passed to Tomcat by the front-end) has or not a particular role. And, in the OAM system globally, the fact that a user has or not access to a particular resource, is already managed at the OAM level; but to which OAM level, unfortunately right now, you do not have access from Tomcat. But in this case, all your accesses to Tomcat webapps *always* happen through the front-end, because it is this front-end which obtains the user-id (from OAM) and later passes it to Tomcat. And this front-end thus *has* access to the OAM data. So what is stopping you from : - not using any authentication/access-control at the Tomcat level - but checking all this at the Apache httpd front-end level ? Example : suppose you have 3 webapps app1, app2, app3. You could have at the front-end level these sections : Location /app1 SetHandler jakarta-servlet (same as JkMount /app1) AuthType Oblix require valid-user require .. (whatever) /Location Location /app2 SetHandler jakarta-servlet (same as JkMount /app2) AuthType Oblix require valid-user require .. (whatever) /Location Location /app3 SetHandler jakarta-servlet (same as JkMount /app3) AuthType Oblix require valid-user require .. (whatever) /Location If the user does not pass muster for /app1 according to OAM, then the call will never even make it Tomcat. If the user passes muster, then you can let them access Tomcat's /app1 application, as they have been checked for it. Or am I missing something ? Hi, Yes, you are missing something, something akin to the last mile. Following your example, of /app1, suppose that that is a webapp that requires a known user (principal). The security JSP example in Tomcat is an example of this. You can use something like OAM to protect (permit or deny) access, but once you get to the /app1, you wouldn't be logged into the app itself, not only for declarative type constraints, but also, for example, if the app does things like give you access to only specified resources (e.g., database tables, etc.) based on who you are. So, for example with the security example, with just OAM, and without anything else, you end up on the form login page, instead of it saying Hi, x. Just some examples there... Ok, I may be misunderstanding the scope of OAM within your organisation, maybe because I am going by the OAM documentation as I was browsingt it on the web. If you are using it only as an SSO system and only to get a user-id, then your example is correct. From the documentation, it just sounded like it is much more than that. What I was trying to say is more or less this : if all accesses to your Tomcat applications necessarily go through the front-end, then for all intents and purposes the front-end and Tomcat are functionally one and the same system. Or, to put it another way, you could consider the front-end as just a part of Tomcat; or again to put it yet another way, your front-end /is/ your Tomcat authentication realm. And whatever information you can obtain at the front-end level, you can pass to Tomcat as request attributes, which attributes you can retrieve in Tomat and pass to your applications, for them to use to make any access decision they want. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Custom realm.authenticate() that would work with any realm - possible?
André Warnier a...@ice-sa.com wrote:
oh...@cox.net wrote:
André Warnier a...@ice-sa.com wrote:
Hi Jim.
As I recall, your original issue was that there is no OAM plugin for
Tomcat, and
therefore, you are doing the OAM authentication within the front-end
Apache, and then
passing the user-id to Tomcat.
And then, you find yourself in Tomcat with a user-id, but without any
roles
corresponding to this user-id.
And in order to get such roles, you are now facing a rather complex
programming issue at
the Tomcat level.
I wrote this before, but let me repeat it : are you not doing a lot of
work un-necessarily
there, and should you not look at this another way ?
As far as I understand these Tomcat-level matters, a role in Tomcat is
used to control
access to resources.
And you seem to use Tomcat's declarative type of acess-control, which
means that you
allow access or not to a given webapp, in function of whether the user-id
(which is passed
to Tomcat by the front-end) has or not a particular role.
And, in the OAM system globally, the fact that a user has or not access to
a particular
resource, is already managed at the OAM level; but to which OAM level,
unfortunately right
now, you do not have access from Tomcat.
But in this case, all your accesses to Tomcat webapps *always* happen
through the
front-end, because it is this front-end which obtains the user-id (from
OAM) and later
passes it to Tomcat. And this front-end thus *has* access to the OAM data.
So what is stopping you from :
- not using any authentication/access-control at the Tomcat level
- but checking all this at the Apache httpd front-end level
?
Example : suppose you have 3 webapps app1, app2, app3.
You could have at the front-end level these sections :
Location /app1
SetHandler jakarta-servlet (same as JkMount /app1)
AuthType Oblix
require valid-user
require .. (whatever)
/Location
Location /app2
SetHandler jakarta-servlet (same as JkMount /app2)
AuthType Oblix
require valid-user
require .. (whatever)
/Location
Location /app3
SetHandler jakarta-servlet (same as JkMount /app3)
AuthType Oblix
require valid-user
require .. (whatever)
/Location
If the user does not pass muster for /app1 according to OAM, then the
call will never
even make it Tomcat.
If the user passes muster, then you can let them access Tomcat's /app1
application, as
they have been checked for it.
Or am I missing something ?
Hi,
Yes, you are missing something, something akin to the last mile.
Following your example, of /app1, suppose that that is a webapp that
requires a known user (principal). The security JSP example in Tomcat is
an example of this.
You can use something like OAM to protect (permit or deny) access, but once
you get to the /app1, you wouldn't be logged into the app itself, not
only for declarative type constraints, but also, for example, if the app
does things like give you access to only specified resources (e.g.,
database tables, etc.) based on who you are. So, for example with the
security example, with just OAM, and without anything else, you end up on
the form login page, instead of it saying Hi, x.
Just some examples there...
Ok, I may be misunderstanding the scope of OAM within your organisation,
maybe because I
am going by the OAM documentation as I was browsingt it on the web.
If you are using it only as an SSO system and only to get a user-id, then
your example is
correct.
From the documentation, it just sounded like it is much more than that.
What I was trying to say is more or less this : if all accesses to your
Tomcat
applications necessarily go through the front-end, then for all intents and
purposes the
front-end and Tomcat are functionally one and the same system. Or, to put it
another way,
you could consider the front-end as just a part of Tomcat; or again to put it
yet another
way, your front-end /is/ your Tomcat authentication realm.
And whatever information you can obtain at the front-end level, you can pass
to Tomcat as
request attributes, which attributes you can retrieve in Tomat and pass to
your
applications, for them to use to make any access decision they want.
Hi Andre,
The thing is, as you yourself mentioned earlier, some (maybe a lot) of systems
(apps), utilize declarative security constraints (e.g., in web.xml), in order
to avoid having to put code in the app that does stuff like (this is just
pseudo-code):
if (user.isInRole(xyz) {
.
.
}
If the app/webapp utilizes declarative security (constraints, etc.), then just
protecting the app's URIs at the Apache isn't sufficient.
I'm not wanting to get in to a debate about the pros/cons of declarative vs.
programmatic. The area that I'm in (my job) is
RE: Custom realm.authenticate() that would work with any realm - possible?
From: oh...@cox.net [mailto:oh...@cox.net] Subject: Custom realm.authenticate() that would work with any realm - possible? I was wondering if there might, perhaps, be another way to do what I'm trying to do (basically have an realm.authenticate() method that doesn't require a password, but that would work with any realm? Look at the CombinedRealm; you might be able to use your no-password realm in conjunction with one of the others, since the doc says Authentication against any Realm will be sufficient to authenticate the user. I don't know if that will get you the necessary roles established. http://tomcat.apache.org/tomcat-7.0-doc/realm-howto.html#CombinedRealm - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
