Sorry for the curiosity,
however, seems to me that user-level OS thread identity requires an cgi interface to initiate separate sub-process to the Operation System. I’m sure Tomcat has it’s own cgi interface classes.
Basically, following initiates a sub-process via Java to execute the system shell to login as a separate user.
runtime = Runtime.getRuntime();
String cmd = "tcsh -s "; //Use the C-shell with receiving commands from stdin
Process cmp = runtime.exec(cmd);
// the following supplies input to the process
BufferedWriter cmdInput = new BufferedWriter(
new OutputStreamWriter(cmp.getOutputStream()));
// the reads the process stdout
BufferedReader cmdOutput = new BufferedReader(
new InputStreamReader(cmp.getInputStream()));
// ... the process stderr
BufferedReader cmdError = new BufferedReader(
newInputStreamReader(cmp.getErrorStream()));
cmdInput.write("…"); // rlogin, telnet, etc…
TomCat And Security
Tomcat runs in a single JVM (single process).
z/OS however has the (somewhat unique) ability to assign/reassign each thread's OS identity. So, it is possible for the servlet container to reassign the thread's OS identity just prior to dispatching a servlet.
BTW - it is possible to launch subprocesses under z/OS java using Runtime.exec(), as you suggest. By default, the subprocess will have the same OS identity as the thread that starts it.
z/OS however has the (somewhat unique) ability to assign/reassign each thread's OS identity. So, it is possible for the servlet container to reassign the thread's OS identity just prior to dispatching a servlet.
BTW - it is possible to launch subprocesses under z/OS java using Runtime.exec(), as you suggest. By default, the subprocess will have the same OS identity as the thread that starts it.
I think that we figured out how to add thread-level OS identity support to Tomcat without modifying the Tomcat code base (by writing a custom Tomcat valve and a bit of new JNI code).
This is not something that is currently near the top of our priority list, but if you have a critical need we could probably arrange to do it as consulting services; what we have in mind would be about a man-week of effort. Please email us off-line if you would like to discuss.
This is not something that is currently near the top of our priority list, but if you have a critical need we could probably arrange to do it as consulting services; what we have in mind would be about a man-week of effort. Please email us off-line if you would like to discuss.
-
Guest
thread security
Thank you very much. I will discuss your offer with my dev team. Would this enhancement be private or open ??
-
Guest
server thread connection mechanism and jzos saf set up ??
I have studied the Single Sign On Valve , and I have also studied your
Saf Realm Implementation.
I have some questions:
When does realm security get executed before of after a http request gets assigned to a thread in the thread pool ????
Can Role checking occur at any time ???
When a Session is created, does that mean all http request transactions will occur on the same thread in the thread pool ????
Is thread pool assignment random for each and every http
transaction request ????
Is their any occasion where the same thread will always handle all transcations from a particular client ???
It seems to me that your saf authenticate function does create a thread level security ( at least temporarilly ) and that your saf check-permissions function would not even work if that were not true.
If I am wrong please explain thanks.
But if I am correct, then I have the following questions:
If realm rules and roles are checked randomly, when-ever a resource is
accessed which would invoke your hasRole method, and if this could occur upon different threads in the thread pool when different http requests get assigned and acted upon, then it seems to me that your
hasRole function will not always work consistently ..
For the hasRole to work consistenly accross different threads in the
thread pool at different times for different http requests, your authenticate function would have to be re-invoked ....
I know I am strugling with incomplete info and a limitted grasp on how
tomcat functions. But I am not unfamiliar with tasks and tcp server processing. I have written a solid mvs tcp server with sub-tasks {with sub-task security} and also in a unix fashion using fork/execmvs (: ...
And I know tomcat uses a thread pool so I assume that the listener accepts a socket and then assigns the connection to a thread in the thread pool. But does that mean every url http request can land on a different thread in the thread pool ????
So please forgive if i am asking off topic or stupid questions (:
Saf Realm Implementation.
I have some questions:
When does realm security get executed before of after a http request gets assigned to a thread in the thread pool ????
Can Role checking occur at any time ???
When a Session is created, does that mean all http request transactions will occur on the same thread in the thread pool ????
Is thread pool assignment random for each and every http
transaction request ????
Is their any occasion where the same thread will always handle all transcations from a particular client ???
It seems to me that your saf authenticate function does create a thread level security ( at least temporarilly ) and that your saf check-permissions function would not even work if that were not true.
If I am wrong please explain thanks.
But if I am correct, then I have the following questions:
If realm rules and roles are checked randomly, when-ever a resource is
accessed which would invoke your hasRole method, and if this could occur upon different threads in the thread pool when different http requests get assigned and acted upon, then it seems to me that your
hasRole function will not always work consistently ..
For the hasRole to work consistenly accross different threads in the
thread pool at different times for different http requests, your authenticate function would have to be re-invoked ....
I know I am strugling with incomplete info and a limitted grasp on how
tomcat functions. But I am not unfamiliar with tasks and tcp server processing. I have written a solid mvs tcp server with sub-tasks {with sub-task security} and also in a unix fashion using fork/execmvs (: ...
And I know tomcat uses a thread pool so I assume that the listener accepts a socket and then assigns the connection to a thread in the thread pool. But does that mean every url http request can land on a different thread in the thread pool ????
So please forgive if i am asking off topic or stupid questions (:
Hello,
In response to questions, I’m getting the idea, you are curious about how HTTP requests are handled (or threaded) via JSP servlets implemented by Tomcat. As what I can tell from what I read about JSP servlets, each http request is handled by a separate thread. Basically, when the client (browser) makes a connection to the server, one or more http requests are serviced prior to the connection (Session) is terminated. Understandingly, the Realm Security, which governs whether or not the visitor is authorized for a given URL, is executed only once after the first thread of the current connection is initiated.
Sometime ago, while using Eclipse trace through the execution of the source code for Tomcat and Jetty, I was curious to how server responses were generated. I’m still not perfectly clear as how the connections were established and terminated, but I have observed that a separate thread was assigned to each http request received by the same browser session. Basically, the thread pool has a preset amount of threads initiated when the server’s http handler(s) are started. When the number of requests coming in exceeds the preset amount, more threads are initiated until a max limit is reached, at that point the requests are stacked until the TCP/IP stacked limit is reached. As what I can tell, each http request is assigned the next thread that is available.
Now each thread executes its own http content (WebApplication/Context) handler. When the protected URL is visited for the first time (from the current connection), the context handler as defined by the security constraints invokes the authenticator which challenges the Visitor for their credentials. The authentication process calls the authenticator method of the current Realm (tied the given URL). Once, authenticated, only then the role checker is then invoked. At which time, the authenticated user must also have a role defined to allow them access to the context path (URL). I’ve observed subsequent http requests (of the same session/connection) to same URL path are not again challenged until the connection is broken. Like for example, the request for a html page is challenged, but the pictures on this page which also are in the same path don’t require additional user authentication even though each are handle by separate individual threads.
Sorry, if I confused you even more. To me sessions are also almost synonymous with connections. When the user initially connects while requesting a single instance of a web page, they are authenticated. Each subsequent http requests (components of the original page) though handled by a separate thread appears to occur on the same connection. All these individual http requests make up this logical session. The session terminates when the connection terminates (or times out).
As to your last statement about tomcat and about accepting TCP/IP sockets, I’m not sure exactly how the Socket Factory (Classes) work. From my observation of tracing through the source code, when the listener accepts a socket, the socket factory assigns that connection to the next available thread. That thread receives the http request from the connection, and sends the http response back through connection, but doesn’t physically close the connection. I believe, the close method just signals the socket factory the connection is available for the next thread and the current thread terminates. Once the browser sends another requests on the same connection, the socket factory simple assigns another thread. But behind the scenes, tomcat is tracking all these sessions.
Likewise, if I was writing my own MVS web server from scratch, I’ll have a master task with accepts incoming sockets, and then give this socket to the next available subtask. That subtask takes the socket and handles all the subsequent http requests sequentially.
In response to questions, I’m getting the idea, you are curious about how HTTP requests are handled (or threaded) via JSP servlets implemented by Tomcat. As what I can tell from what I read about JSP servlets, each http request is handled by a separate thread. Basically, when the client (browser) makes a connection to the server, one or more http requests are serviced prior to the connection (Session) is terminated. Understandingly, the Realm Security, which governs whether or not the visitor is authorized for a given URL, is executed only once after the first thread of the current connection is initiated.
Sometime ago, while using Eclipse trace through the execution of the source code for Tomcat and Jetty, I was curious to how server responses were generated. I’m still not perfectly clear as how the connections were established and terminated, but I have observed that a separate thread was assigned to each http request received by the same browser session. Basically, the thread pool has a preset amount of threads initiated when the server’s http handler(s) are started. When the number of requests coming in exceeds the preset amount, more threads are initiated until a max limit is reached, at that point the requests are stacked until the TCP/IP stacked limit is reached. As what I can tell, each http request is assigned the next thread that is available.
Now each thread executes its own http content (WebApplication/Context) handler. When the protected URL is visited for the first time (from the current connection), the context handler as defined by the security constraints invokes the authenticator which challenges the Visitor for their credentials. The authentication process calls the authenticator method of the current Realm (tied the given URL). Once, authenticated, only then the role checker is then invoked. At which time, the authenticated user must also have a role defined to allow them access to the context path (URL). I’ve observed subsequent http requests (of the same session/connection) to same URL path are not again challenged until the connection is broken. Like for example, the request for a html page is challenged, but the pictures on this page which also are in the same path don’t require additional user authentication even though each are handle by separate individual threads.
Sorry, if I confused you even more. To me sessions are also almost synonymous with connections. When the user initially connects while requesting a single instance of a web page, they are authenticated. Each subsequent http requests (components of the original page) though handled by a separate thread appears to occur on the same connection. All these individual http requests make up this logical session. The session terminates when the connection terminates (or times out).
As to your last statement about tomcat and about accepting TCP/IP sockets, I’m not sure exactly how the Socket Factory (Classes) work. From my observation of tracing through the source code, when the listener accepts a socket, the socket factory assigns that connection to the next available thread. That thread receives the http request from the connection, and sends the http response back through connection, but doesn’t physically close the connection. I believe, the close method just signals the socket factory the connection is available for the next thread and the current thread terminates. Once the browser sends another requests on the same connection, the socket factory simple assigns another thread. But behind the scenes, tomcat is tracking all these sessions.
Likewise, if I was writing my own MVS web server from scratch, I’ll have a master task with accepts incoming sockets, and then give this socket to the next available subtask. That subtask takes the socket and handles all the subsequent http requests sequentially.
(addressing the previous to last post)
The current SAF security realm does not change the thread identity.
Please refer to the ZUtil.authenticate() and ZUtil.hasPermission() methods which document the C-library calls made (which are documented in the IBM "z/OS C/C++ Library Reference")
Therefore, its really irrelavant when it gets called, and on what thread.
mwilliams' description about how Tomcat realm security works seems right to me.
The current SAF security realm does not change the thread identity.
Please refer to the ZUtil.authenticate() and ZUtil.hasPermission() methods which document the C-library calls made (which are documented in the IBM "z/OS C/C++ Library Reference")
Therefore, its really irrelavant when it gets called, and on what thread.
mwilliams' description about how Tomcat realm security works seems right to me.
-
Guest
Thread Security And Stupid Nebie Java Questgion
Thanks to everyone for their help.
I am trying to modify the SingleSignOn valve to create a thread security
contect.
I have renamed both classes:
SingleSignOn -> ThreadSignOn
SingleSignOnEntry -> ThreadSignOnEntry
But when I try to compile either I get compiler errors because of a circuler refference !! SingleSignOnEntry makes reff to SingleSignOn
And singlesignon makes reff to singlesingonentry !!!
And there is no import , How do I declare a class without first compiling that class
I am trying to modify the SingleSignOn valve to create a thread security
contect.
I have renamed both classes:
SingleSignOn -> ThreadSignOn
SingleSignOnEntry -> ThreadSignOnEntry
But when I try to compile either I get compiler errors because of a circuler refference !! SingleSignOnEntry makes reff to SingleSignOn
And singlesignon makes reff to singlesingonentry !!!
And there is no import , How do I declare a class without first compiling that class
-
Guest
Creating a New Valve ??
Never mind my previous question/post. I solved it by setting my classpath ..
Now I have a new question How do I deploy my new Valve ???
It is basically compiled as part of the "authenticator" package.
Does that mean I have to include it in the authenticator jar ???
Can a package be split between two jar files ???
Now I have a new question How do I deploy my new Valve ???
It is basically compiled as part of the "authenticator" package.
Does that mean I have to include it in the authenticator jar ???
Can a package be split between two jar files ???
The compiler handles that for you, so long as you compile both classes with the same invocation of javac.
The valve class can be in any package, but it must be in a jar in "server/lib" (or individual class files in "server/classes"). Check the Tomcat documentation.
...
http://en.wikipedia.org/wiki/Self-surgery
The valve class can be in any package, but it must be in a jar in "server/lib" (or individual class files in "server/classes"). Check the Tomcat documentation.
...
http://en.wikipedia.org/wiki/Self-surgery
-
Guest
Thanks again, I just read the chapter on class loaders in the wrox book
on tomcat (5)....
This is wierd I rebuilt tomcat which included my new valve classes into
catalena.jar, i copied the new jar, and added my new valve statement, but it did not work....
I also noticed that the SingleSignOn valve has a property defined in the
mbeans xml descriptor file that does not show up in admin.
the re-authenticate property, (maybee it should be declared public instead of private ) ????
on tomcat (5)....
This is wierd I rebuilt tomcat which included my new valve classes into
catalena.jar, i copied the new jar, and added my new valve statement, but it did not work....
I also noticed that the SingleSignOn valve has a property defined in the
mbeans xml descriptor file that does not show up in admin.
the re-authenticate property, (maybee it should be declared public instead of private ) ????