I finally got Tomcat 6.0.18 configured and running with my userid as the manager. I can enter my userid and password and it lets me manage it. Now what I need is for TOMCAT to authenticate all users that come in and when they use an application that is written to access datasets, it will check RACF to see if they have the authority to access it.
Previously we are running the IBM http webserver with a very old websphere plugin (version 3.5). Years ago we wrote an application to allow users to browse MVS datasets or to convert them to PDF datasets on the fly. As soon as we would log in to the http server it asks for our userid and passwords, which it would then use to check to see if we had access to the GDG's. It just used our racf security. We didn't have to define any new rules.
Can this be done with TOMCAT?
Thanks,
Gary
________
silversurfer reviews
TOMCAT SAF security and Dataset Access
TOMCAT SAF security and Dataset Access
Last edited by gpklos on Mon Feb 07, 2011 8:36 pm, edited 1 time in total.
Our custom SAF realm for Tomcat on z/OS does two things:
1) it can be used to validate the users id and password using your z/OS security product (RACF, ACF2, etc).
2) It can be used to assign J2EE "roles" to a user, based on SAF classes/rules.
What it *doesn't* do is actually assign the browser user's z/OS userid as the "running" userid for the Tomcat job (or thread). So, the Tomcat job and all threads (servlet executions) still run in the z/OS userid assigned to the batch job. Any dataset access (or other z/OS security accesses) will be assigned based on the userid running the Tomcat job or started task.
Websphere has a facility known as "Run As", which causes a thread that runs a servlet request to be switched to the ACEE (security context) of the browser user that had previously authenticated. We don't currently support something like this with our z/OS Tomcat extensions, although we have considered adding it. This is not without problems (in WAS as well), since it means that the running Java code is switched to run as a userid that may or may not have access to all of the resources needed to run the Tomcat code (the class files, jars, etc). So it can be problematic in WAS to do this, and if we did it in Tomcat it would have the same issues.
In most cases, running the container (Tomcat or WAS) using the job's userid is best. You can then use your own code in the web application to authenticate access to resources using J2EE "role" checks. After all, in may applications it is OK for the "server" to access datasets that the user can't access directly. Consider CICS as an example.
But in some applications, like the one you mention, it seems nice to be able to "run as" the end user in the executing thread. We will consider adding this feature in the future.
1) it can be used to validate the users id and password using your z/OS security product (RACF, ACF2, etc).
2) It can be used to assign J2EE "roles" to a user, based on SAF classes/rules.
What it *doesn't* do is actually assign the browser user's z/OS userid as the "running" userid for the Tomcat job (or thread). So, the Tomcat job and all threads (servlet executions) still run in the z/OS userid assigned to the batch job. Any dataset access (or other z/OS security accesses) will be assigned based on the userid running the Tomcat job or started task.
Websphere has a facility known as "Run As", which causes a thread that runs a servlet request to be switched to the ACEE (security context) of the browser user that had previously authenticated. We don't currently support something like this with our z/OS Tomcat extensions, although we have considered adding it. This is not without problems (in WAS as well), since it means that the running Java code is switched to run as a userid that may or may not have access to all of the resources needed to run the Tomcat code (the class files, jars, etc). So it can be problematic in WAS to do this, and if we did it in Tomcat it would have the same issues.
In most cases, running the container (Tomcat or WAS) using the job's userid is best. You can then use your own code in the web application to authenticate access to resources using J2EE "role" checks. After all, in may applications it is OK for the "server" to access datasets that the user can't access directly. Consider CICS as an example.
But in some applications, like the one you mention, it seems nice to be able to "run as" the end user in the executing thread. We will consider adding this feature in the future.
So if understand this correctly to get it to work with the way you describe (in RED below), I would have to define roles for each userid and have an entry for each dataset they would need to access. Essentially remapping what is currently in RACF to EJBROLEs? Correct?
Thanks
<<In most cases, running the container (Tomcat or WAS) using the job's userid is best. You can then use your own code in the web application to authenticate access to resources using J2EE "role" checks. After all, in may applications it is OK for the "server" to access datasets that the user can't access directly. Consider CICS as an example.
>>
________
CBR400RR
Thanks
<<In most cases, running the container (Tomcat or WAS) using the job's userid is best. You can then use your own code in the web application to authenticate access to resources using J2EE "role" checks. After all, in may applications it is OK for the "server" to access datasets that the user can't access directly. Consider CICS as an example.
>>
________
CBR400RR
Last edited by gpklos on Mon Feb 07, 2011 8:36 pm, edited 1 time in total.
That's right. Its far from ideal if you want to allow for *any* dataset or a large set of datasets, but it might be OK if there are simply a few datasets that you need to allow access to, or you can organize them by "Levels" and assign a role name to each level. Again, you will also have to change the Java code to check the role (HttpServletRequest.isUserInRole()).