John, you are absolutely right. If you configure the web server and
servlet engine as you have done, then you can get the effect you
describe.
You and I are looking at the problem from different points view.
In your case, it's your web server, and you can configure the server
exactly as you see fit.
In my case I'm trying to sell a product (to sites like yours :) where my
application may not be the only application hosted on that web server.
Since my application needs to "fit in" with the customer's other
applications, I cannot count on a particular web server/servlet engine
configuration.
If you are running the servlet engine (WebSphere) out of process (and
perhaps if in WLM mode?), or if the customer chooses not to authenticate
against OS/390 native security, then the thread that calls JNI will not
have the native security context of the authenticated user. So I can't
use it or count on it.
I'm not sure if I'd call IBM OS/390 "unix on steriods" :), but I would
agree that IBM is moving in (IMHO) exactly the right direction to make
the mainframe and interesting platform for web applications.
From: Zerbe John W
> Many people, even here within our corporation, don't realize the
> OS/390 mainframe operating system now contains what I consider to be a
> "unix kernal on steriods" complete with a hierarchical file system.
> IBM implemented its "unix threads" by extending the capabilities of
> the older MVS TCBs (Task Control Blocks). OS/390 (the newest name for
> MVS) has the ability to assign different security environments to
> different tasks running within the same address space / process.
>
> We actually have IBM's mainframe (Domino Go) web server installed in
> the "Unix System Services" of one of our test mainframe LPARs. With
> its basic authentication turned on, it really authenticates the userid
> and password against our CA-ACF2 (mainframe) security database. This
> has a side effect of really setting up a mainframe security
> environment in the web server for that userid. For subsequent
> requests, the "unix" thread in the web server really runs with the
> security environment of the end user. Since the JVM is running "in
> process", the thread in the JVM continues to run with that mainframe
> security environment. I tested this by creating a servlet that was
> protected by the authentication and setting the unix file protection
> flags so that only my userid had read access to the class file. I
> could invoke the servlet myself but a co-worker could not. The logs
> showed an authorization failure. I changed the protection flags on the
> class file to have read access to the world, and then my co-worker
> could then load and run the servlet.
>
> Yes, this is really relevant for JNI calls. The current native DB2
> JDBC driver for OS/390 is implemented roughly as an ODBC-JDBC bridge
> that won't accept a userid/password on the connect. It uses the
> security environment already set up for the running thread and won't
> allow any thread to use the connection other than the one that
> initiated the connection. So much for connection pooling! This may
> sound like a problem, but since you are running in the same mainframe
> as the DB2 database that you are connecting to, the connection time is
> not bad. I also have servlets connecting to MQ-Series Queue Managers
> in that LPAR. The only network related "lag time" is for the HTTP
> communication.
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
