If I just want to enable hfs and dataset security, do I still need to set up
a "role".. I just want normal authenticate change user to be performed.
When you say the jzos loadmod should be program controlled do you really mean apf authorized ???
Shouldn't your modules be linked ac=1 ????
What is the diiference between program controlled and apf authorized, I thought they meant the same thing ????
Are their any sample apps that demonstrate a standard login that would invoke the racroute authenticate code ????
TomCat And Security
I'm not sure what you mean by "implementing hfs and dataset security". Normal z/OS security applies to the Tomcat job as well, but the Tomcat server runs under whatever userid that the job or started task runs under.
Tomcat on z/OS doesn't support running servlet threads under the unique userid of the browser's authenticated user. This would require patches to Tomcat itself, and we haven't patched Tomcat in any way to run it under z/OS. Is this your requirement? z/OS Websphere is the only container on any platform that I know of that will do this.
What we do support is authenticating end users with SAF and assigning roles to those users based on SAF rules. This is the normal web security model, and allows security to be assigned to web resources via web.xml or by programmer coded checks to see if the current user has a particular role.
The JZOS Tomcat SAF authentication is done in the com.dovetail.jzos.tomcat package, source for which is part of the distribution.
Hope this helps...
Tomcat on z/OS doesn't support running servlet threads under the unique userid of the browser's authenticated user. This would require patches to Tomcat itself, and we haven't patched Tomcat in any way to run it under z/OS. Is this your requirement? z/OS Websphere is the only container on any platform that I know of that will do this.
What we do support is authenticating end users with SAF and assigning roles to those users based on SAF rules. This is the normal web security model, and allows security to be assigned to web resources via web.xml or by programmer coded checks to see if the current user has a particular role.
The JZOS Tomcat SAF authentication is done in the com.dovetail.jzos.tomcat package, source for which is part of the distribution.
Hope this helps...
Sorry, I forgot to answer your question about "program controlled" vs "apf authorized".
The SAF Realm that we wrote for Tomcat only uses apis that require a program-controlled environment and not "apf authorization".
APF authorization is much more dangerous, and should never be given to applications if not needed. Its the rough equivalent of "root" on z/OS.
See the SAF how-to document for more information:
http://jzos.com/docs/saf.html
The SAF Realm that we wrote for Tomcat only uses apis that require a program-controlled environment and not "apf authorization".
APF authorization is much more dangerous, and should never be given to applications if not needed. Its the rough equivalent of "root" on z/OS.
See the SAF how-to document for more information:
http://jzos.com/docs/saf.html
source code
were is the source code ???
i thought jzos was open source ???
i thought jzos was open source ???
Please read my previous post:
This source is in the JZOS distribution home directory, under the src directory. Included in the src is a copyright and reference to the license (the Apache 2.0 license).The JZOS Tomcat SAF authentication is done in the com.dovetail.jzos.tomcat package, source for which is part of the distribution.
-
Guest
Thread level security is possible:: ( pthread_security_np )
To implement thread level security all you have to do is
pthread_security_np ( )
Can you add a JNI wrapper function to implement this ????
pthread_security_np ( )
Can you add a JNI wrapper function to implement this ????
There are a couple of outstanding questions -
- I think that adding thread-level security is a bit more complicated than just adding a call to this function. It would definitely require patches to Tomcat. We would consider adding a JNI wrapper for for pthread_security_np ( ) if there is demand for it. Personally, I'm not in favor of patching Tomcat for thread-level user security. I suppose that it would be nice for some kinds of web applications, but its a concept that web servers on other platforms don't have and noone seems to mind.
- the C++ and assembler source code for the launcher and the JZOS JNI library are not currently distributed. (The binaries for these -are- distributed under the Apache 2.0 license). All of the Java source code, including the Tomcat security realm, is distributed under the Apache 2.0 license, and each Java JNI wrapper method documents the OS api calls that are made.
- If you wanted to write a Jetty LogonModule, you can certainly use the SAF JNI wrappers in the ZUtil class to implement identity and role checking.
- I think that adding thread-level security is a bit more complicated than just adding a call to this function. It would definitely require patches to Tomcat. We would consider adding a JNI wrapper for for pthread_security_np ( ) if there is demand for it. Personally, I'm not in favor of patching Tomcat for thread-level user security. I suppose that it would be nice for some kinds of web applications, but its a concept that web servers on other platforms don't have and noone seems to mind.
- the C++ and assembler source code for the launcher and the JZOS JNI library are not currently distributed. (The binaries for these -are- distributed under the Apache 2.0 license). All of the Java source code, including the Tomcat security realm, is distributed under the Apache 2.0 license, and each Java JNI wrapper method documents the OS api calls that are made.
- If you wanted to write a Jetty LogonModule, you can certainly use the SAF JNI wrappers in the ZUtil class to implement identity and role checking.
-
Guest
security ??
I do not understand why unix people have such a careless cavalear attitude towards security. To me running a server as root is a serious
and dangerous security risk. On IBM systems your response is going to be greeted with scornfull replies.
If you cannot implement thread level security then tomcat can not be used for serious system and or production work.. it is nothing more than play thing , a toy,
and dangerous security risk. On IBM systems your response is going to be greeted with scornfull replies.
If you cannot implement thread level security then tomcat can not be used for serious system and or production work.. it is nothing more than play thing , a toy,
Who said anything about running Tomcat as root?
WebSphere for z/OS is the only container (on any platform) that I know of that allows each user request's thread to be assigned to that user's OS identity. In other containers, threads run with the OS identity of the server process. Websphere supports this mode as well, which is what most people want.
Take an example: you have a z/OS Java servlet that updates the "customer master" VSAM cluster. You assign the end user to a security role (via SAF if you like) that allows access to this servlet. Tomcat runs under a SAF identity that has update access to the VSAM cluster and all Java threads run under this same server identity. Doesn't this parallel how (toy) CICS applications work?
Under the same example, if you used Websphere for z/OS and configured it for end-user OS thread identity, then each end user of your servlet would require SAF update access to the VSAM cluster. What prevents that user from uncontrolled updates via a batch job, TSO session, etc?
I can imagine applications where end-user thread-level OS identity would be nice, but they are far more uncommon IMO. If you need this, you should probably consider WebSphere (for z/OS; Websphere on Unix has no such concept)
WebSphere for z/OS is the only container (on any platform) that I know of that allows each user request's thread to be assigned to that user's OS identity. In other containers, threads run with the OS identity of the server process. Websphere supports this mode as well, which is what most people want.
Take an example: you have a z/OS Java servlet that updates the "customer master" VSAM cluster. You assign the end user to a security role (via SAF if you like) that allows access to this servlet. Tomcat runs under a SAF identity that has update access to the VSAM cluster and all Java threads run under this same server identity. Doesn't this parallel how (toy) CICS applications work?
Under the same example, if you used Websphere for z/OS and configured it for end-user OS thread identity, then each end user of your servlet would require SAF update access to the VSAM cluster. What prevents that user from uncontrolled updates via a batch job, TSO session, etc?
I can imagine applications where end-user thread-level OS identity would be nice, but they are far more uncommon IMO. If you need this, you should probably consider WebSphere (for z/OS; Websphere on Unix has no such concept)
-
mwilliams
follow up questions on security
Hello,
I see that all of your discussions about security is very interesting.
However, as with most architectures isn’t true for a given address space (MVS), process (Unix) is assigned authority the governed by the operating system? And that each thread within the parent process inherits the same authority. Isn’t it the responsibility of the container such as CICS, WebSpere, etc. to authentic the user logon via services from SAF, etc? I thought whenever a new thread is initiated, the container assures the proper level of security is exercised. As such the container directly governs what each thread has access to base upon the logical user authenticated and roles assigned.
For example, when a user logs onto CICS, doesn’t CICS make calls to RACF, SAF, etc. for verification that the current user has authority to execute transactions of which operator wants to execute?
Now, contrast from above, whenever a user logs on to TSO, a separate address space is initiated by the operating system and of which the operating system via RACF handles authority. Likewise, the same sort of process happens with UNIX. As for TSO, RACF directly governs which data sets the user has access to.
My point is that, shouldn’t the security routines within Tomcat, govern which servlets the user has rights to access? Should we also address any possible security loop holes, and not focus some much on whether each thread has been assigned a separate user id from SAF?
I see that all of your discussions about security is very interesting.
However, as with most architectures isn’t true for a given address space (MVS), process (Unix) is assigned authority the governed by the operating system? And that each thread within the parent process inherits the same authority. Isn’t it the responsibility of the container such as CICS, WebSpere, etc. to authentic the user logon via services from SAF, etc? I thought whenever a new thread is initiated, the container assures the proper level of security is exercised. As such the container directly governs what each thread has access to base upon the logical user authenticated and roles assigned.
For example, when a user logs onto CICS, doesn’t CICS make calls to RACF, SAF, etc. for verification that the current user has authority to execute transactions of which operator wants to execute?
Now, contrast from above, whenever a user logs on to TSO, a separate address space is initiated by the operating system and of which the operating system via RACF handles authority. Likewise, the same sort of process happens with UNIX. As for TSO, RACF directly governs which data sets the user has access to.
My point is that, shouldn’t the security routines within Tomcat, govern which servlets the user has rights to access? Should we also address any possible security loop holes, and not focus some much on whether each thread has been assigned a separate user id from SAF?
I agree 100%....
and that is how Tomcat with the JZOS SAF Security realm works.
That is -
- Users are authenticated when they login (userid / password)
- Users are assigned to web container "roles" which are mapped to SAF entity permissions.
- Tomcat uses these roles and security contraints in web.xml to authorize access to servlets. In addition, explicit checks can be coded by the application (HttpServletRequest.isUserInRole())
- All threads in Tomcat run with same OS identity as the Tomcat server address space. The server id doesn't require root or APF authorization, only read access to BPX.SERVER facility.
and that is how Tomcat with the JZOS SAF Security realm works.
That is -
- Users are authenticated when they login (userid / password)
- Users are assigned to web container "roles" which are mapped to SAF entity permissions.
- Tomcat uses these roles and security contraints in web.xml to authorize access to servlets. In addition, explicit checks can be coded by the application (HttpServletRequest.isUserInRole())
- All threads in Tomcat run with same OS identity as the Tomcat server address space. The server id doesn't require root or APF authorization, only read access to BPX.SERVER facility.
-
Guest
security
All of the above makes perfect sense if you are designing a server which requires access to system recources on a very very limited scope.
I am trying to design a server process that does Host Software Installation with a user friendly gui front end.
As such the (scope ) of what it can access is (variable and unlimitted). Because it depends on what-ever scope or access to the system is allowed on a per-user basis. This is why I am trying to establish thread level security.
Some users may be system programmers with unlimmited authority to install anything anywhere. Other users may be qa or development with authority to install only under the userid or group authorities that belong to them.
So now you see the reason behind my requirements.
I am trying to design a server process that does Host Software Installation with a user friendly gui front end.
As such the (scope ) of what it can access is (variable and unlimitted). Because it depends on what-ever scope or access to the system is allowed on a per-user basis. This is why I am trying to establish thread level security.
Some users may be system programmers with unlimmited authority to install anything anywhere. Other users may be qa or development with authority to install only under the userid or group authorities that belong to them.
So now you see the reason behind my requirements.
Yes, I understand the requirement for user-level OS thread identity. It makes perfect sense in some situations, although I think that they are not that common. An example that I can think of would be some kind of file server built on top of HTTP servlets where you would definitely want the end-users' SAF access to be used for reading and writing files.
It is of course possible to modify Tomcat to assign user-level OS thread identity to each servlet invocation. I don't think that you can do it solely through a custom Realm class, but I could be wrong. Perhaps a user-written "Valve" class might work. It might be easier to do it in Jetty, since it has its own pluggable login module framework, built on JAAS, but I'm not sure.
You might try posting a question in the Tomcat developer list or similar Jetty forum for guidance on the how to customize the container for user-level OS thread identity.
http://mail-archives.apache.org/mod_mbo ... omcat-dev/
It is of course possible to modify Tomcat to assign user-level OS thread identity to each servlet invocation. I don't think that you can do it solely through a custom Realm class, but I could be wrong. Perhaps a user-written "Valve" class might work. It might be easier to do it in Jetty, since it has its own pluggable login module framework, built on JAAS, but I'm not sure.
You might try posting a question in the Tomcat developer list or similar Jetty forum for guidance on the how to customize the container for user-level OS thread identity.
http://mail-archives.apache.org/mod_mbo ... omcat-dev/