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, xxxxx".
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 if some group has an app that utilizes declarative security, we need to be
able to deliver what is needed to enable that. Conversely, if some group has
an app that uses programmatic security, then we need to do the same for them.
Ok, I get you.
Well then, it seems that you indeed will have to create a real OAM Realm for
Tomcat.
And you'll have to somehow figure out a translation between the Tomcat notion of "role",
and whatever notion OAM has in that respect.
Because it would probably not make much sense to have 2 parallel authorization
infrastructures.
That is a common problem when you try to mix and match two different AAA
schemes.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
