Tomcat authentication and RACF

[Brian Jennings]

Hello,

I'm trying to see if what I want to do is even possible.

I've taken over the authentication portion of our application.

Currently our production environment uses WAS 6.1 on a mainframe server and authenticates users against RACF.

Our development environment however, is Tomcat running with MyEclipse. The previous developer got the application working fine witha new form based login in WAS6.1 on the server but cannot get it to run locally in Tomcat.

I did try MyEclipse Blue and WAS 6.1 locally with no luck. Since this is not a WAS forum, I will not get into the issues there.

So my task is to either get the form based login to work in Tomcat or to find some way to allow our developers to test locally without the login feature getting in the way.

Any suggestions on where to start?

I'm not familiar with authentication and how it's handled in Tomcat, but it appears that Tomcat has its own authentication method and cannot interface with RACF. Is this the case?

Is there a way to force successful login if on the development server? Are there other options I may not be aware of?

My only option that I can currently see is to use an old web.xml for development machines that does not use form based authentication. Maybe I can set up some 'development environment only' tomcat authorization?

Thanks

[Tim Holloway]

Based on my own experience, Tomcat development for WebSphere deployment is a bit of a risk. Tomcat isn't a full-stack J2EE server and WebSphere is. On the other hand, WebSphere is a typically conservative business platform and lags technology quite a bit relative to Tomcat. I worked with someone to produce a WebSphere app from a Tomcat test environment and it was pain enough to get it to port to WAS on Linux, and we finally gave up on getting the port to run on iSeries and just decided to let the iSeries box proxy to an Intel-based Tomcat server.

The security system that Tomcat apps use is defined by the J2EE/JEE standards. That specifies how the apps are secured. Providing the actual authentication and authorization services, however, is done by a plug-in component called a Realm. The Realm component plugs into Tomcat, not the webapp, and the webapp will be totally unaware of what Realm is in use. Which can be handy for testing, since you can simply throw together a tomcat-users.xml file and use the MemoryRealm on the test/development machine without having to tie into the production security system where the rules may be very different (for example, using Active Directory). Likewise, this sort of setup works for stuff that would be on WAS in production, since the security rules and code are J2EE and not dependent on Tomcat or WAS.

I would be very surprised if there isn't a Tomcat RACF Realm module floating around somewhere, although you may have to dig for it. RACF is a very powerful system, but it's a mainframe system, and the bulk of the web isn't mainframe anymore, especially in regards to Tomcat. I'd expect there to be at least one JNI class in a RACF Realm, since the RACHECK functions require SVC interface to zOS and that's a hardware/OS specific function.

You can't do quite everything in a Tomcat Realm that RACF supports. For example, Tomcat supports only 2 credentials for authentication and authorization, although that's all we tended to use in the mainframe shops where I worked anyway. Still, for testing purposes, you're probably OK. Just need to locate the module, plugin it in, and configure the application contexts to use it.

[Brian Jennings]

Thanks for the info, Tim! I'll look into that.

I tried using our new login page in Tomcat with SSL, and it appears to work with the realm we had before the form login was added.

The only problem now is that with SSL our images in the /images directory are not being displayed.

Is there a setup required to allow the browser to access images and similar resources under SSL and Tomcat?



I agree that mixing environments is not optimal, but we have had no problems deploying our system to the mainframe server. it's only the development environment that is giving us issues with the new form based login.

We will be switching to WAS locally eventually, as well as from Windows XP & IE6 to Windows 7 & IE8. It's a government shop and is slow to change!

[Brian Jennings]

I found the SAF Realm info at Dovetail:

http://dovetail.com/docs/misc/saf.html

I downloaded the SAFRealm.zip and followed the instructions.

I'm now getting this error when trying to login:

java.lang.NoClassDefFoundError: com/ibm/os390/security/PlatformUser
at com.dovetail.zos.tomcat.SafRealm.authenticate(SafRealm.java:167)
...

This is strange because all the required jars including where PlatformUser is defined are in my class path.

I still have the images problem too.

[Tim Holloway]

The Tomcat Realm jar has to be deployed into the TOMCAT_HOME/lib directory (Tomcat 6) or the Tomcat system library directory (Tomcat 5). Don't include it in the WAR. As I said, the WAR doesn't know/care what Realm you use.

You cannot force login on Tomcat 6 and earlier. Tomcat itself handles the login when it detects the need for an authorized user, typically because someone requested a protected URL. Which eliminates one of the primary faults of the DIY security systems (they often think that users are honest enough to go through the normal URL sequence).

Calling the login form from application code doesn't work. Starting in Tomcat7, a login() method has been added to the JEE spec that allows application code to do an internal call to the Realm authenticator.

When using J(2)EE container-based authorization, you must ensure that any scripts, images, and other resources referenced on/before the login/loginfail forms are accessed via "unprotected" URLs. You haven't logged in yet, so any image URL that's protected would itself reflect into a login request instead of returning the image. Same for scripts and so forth.

[Brian Jennings]

Yep, the realm jar file is in the appropriate place, no issue there.

PlatformUser is an IBM provided class that is meant to connect to RACF. We are using the following Jars in the application to allow connection to RACF:
Security.jar, IRRRacf.jar, J2EE.jar


I'm using Tomcat 5.5. I probably should have mentioned that earlier.

Since this application is being migrated to a WAS Server on a mainframe for testing/production, I need to find a way to use the application on a local development server (local to my PC). I'm not even sure RACF on the mainframe is available going through Tomcat.

Our web.xml is set up to recognise form based login. For WAS we have a login filter among other settings. As you said, Tomcat ignores these settings and triggers the logon page when I try to navigate to the starting servlet for the application.


How do I set up unprotected URLS locally so that I can access the images?

Thanks again!

[Tim Holloway]

IIRC, you can designate a URL pattern as "unprotected" by simply giving it an empty security role list. I normally protect sensitive areas (URLs under "/admin", for example, but leave the resources and public (welcome) page unprotected, so I don't have much practice on that one.

You should not explicitly include j2ee.jar in your webapp. It's part of the Tomcat server, although not necessarily under that name or even in a single jar. You should DEFINITELY not borrow the j2ee.jar from WebSphere, as it would be WebSphere-specific. Failure to observe the above admonitions will cause classpath conflicts and unpredictable behavior. Calling RACF functions within a webapp should be OK - they would apply above and beyond the J2EE standard security, however. Consult IBM for details, especially since they might have made those particular jars WAS-specific.

If I were you, I'd also look to see if there's a Redbook published for Tomcat on IBM. If you can find one, it should help considerably.

Also, I just realized you're attempting this on a non-Z machine. I'm not familiar with client/server RACF - meaning RACF on a PC. That's after my mainframe heyday, but I have to presume that IBM is providing something either under that name or perhaps under the Tivoli aegis. You cannot borrow zOS RACF interface classes directly, since the Intel and zSeries binaries are totally incompatible and anything that does a direct RACHECK has to issue an RACHECK SVC. Which is kind of hard to do on a PC, since the Intel equivalent of SVC is the "INT" instruction and binary incompatibilities aside, there's no INT service in either Windows or Linux for security. They handle security in a completely different manner.

[Brian Jennings]

Thanks for all the help, Tim. It's becoming clearer to me!

I see what you mean about not trying to access racf from the local PC version of the server. I suspected that would be a problem.

I'll stick to trying to get this image issue resolved, as hopefully that will let me log on to the application locally via the Tomcat security already in place.

Below is the web.xml we are using, with specific identifying info removed. (specific package name etc)

'myuser' is defined in Tomcat in the tomcat-users file, and is what we use to login (to our local development server) prior to setting up the new form based authentication. Currently, it seems to authenticate fine using 'myuser' in form-based but cannot display the images (causing the application to fail after redirection back to the servlet)

I haven't been ale to find the syntax on how to specify an empty security role list for a directory (/images). What would the syntax be? We have a security role set up for 'myuser' as shown below.

Thanks!

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app id="WebApp">
<display-name>sps</display-name>
<filter>
<filter-name>FormLoginFilter</filter-name>
<display-name>FormLoginFilter</display-name>
<filter-class>....login.FormLoginFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>FormLoginFilter</filter-name>
<url-pattern>/j_security_check</url-pattern>
</filter-mapping>
<servlet>
<servlet-name>WelcomeServlet</servlet-name>
<display-name>WelcomeServlet</display-name>
<servlet-class>....servlets.WelcomeServlet</servlet-class>
</servlet>
<servlet>
<servlet-name>DispatcherServlet</servlet-name>
<display-name>DispatcherServlet</display-name>
<servlet-class>....servlets.DispatcherServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>WelcomeServlet</servlet-name>
<url-pattern>/servlet/....servlets.WelcomeServlet</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>DispatcherServlet</servlet-name>
<url-pattern>/servlet/....servlets.DispatcherServlet/*</url-pattern>
</servlet-mapping>
<welcome-file-list>
<welcome-file>servlet/....servlets.DispatcherServlet?l=e</welcome-file>
<welcome-file>index.html</welcome-file>
<welcome-file>index.htm</welcome-file>
<welcome-file>index.jsp</welcome-file>
<welcome-file>index.xtp</welcome-file>
<welcome-file>default.html</welcome-file>
<welcome-file>default.htm</welcome-file>
<welcome-file>default.jsp</welcome-file>
</welcome-file-list>
<taglib>
<taglib-uri>/our_taglib.tld</taglib-uri>
<taglib-location>/WEB-INF/sps_taglib.tld</taglib-location>
</taglib>
<resource-ref id="ResourceRef_1122386543187">
<res-ref-name>jdbc/our_ref</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
<res-sharing-scope>Shareable</res-sharing-scope>
</resource-ref>
<security-constraint>
<web-resource-collection>
<web-resource-name>myuser</web-resource-name>
<url-pattern>/servlet/*</url-pattern>
<http-method>GET</http-method>
<http-method>PUT</http-method>
<http-method>HEAD</http-method>
<http-method>TRACE</http-method>
<http-method>POST</http-method>
<http-method>DELETE</http-method>
<http-method>OPTIONS</http-method>
</web-resource-collection>
<auth-constraint>
<description></description>
<role-name>myuser</role-name>
</auth-constraint>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
<login-config>
<auth-method>FORM</auth-method>
<realm-name>My-Application-System</realm-name>
<form-login-config>
<form-login-page>/LoginForm.jsp</form-login-page>
<form-error-page>/AuthFailed.jsp</form-error-page>
</form-login-config>
</login-config>
<security-role>
<description></description>
<role-name>myuser</role-name>
</security-role>
</web-app>

[Tim Holloway]

User IDs are not part of web.xml. Only roles. You map a user to one or more roles in your authorization resource (tomcat-users.xml) and map the roles to web resources (such as URLs) however you need them. That way you can change a user's rights without modifying the webapp - just update the permitted roles for the user.

An empty role mapping should look like this, assuming that the J2EE spec works that way.

<role-name></role-name> 

However, I'd have to RTFM to verify. I haven't done one lately.

[Brian Jennings]

I may have misspoke, MyUser in the web.xml seems to be identifying the web resource name, and is associated with the URL path containing our application.

Please keep in mind this is all pretty new to me, thanks for your patience!

So would I define a second web resource name associated with our images directory and then not assign it a security role, as below?

<web-resource-collection>
<web-resource-name>myuser</web-resource-name>
<url-pattern>/servlet/*</url-pattern>
...
<web-resource-name>images</web-resource-name>
<url-pattern>/servlet/images/*</url-pattern>
..
</web-resource-collection>
<auth-constraint>
<description></description>
<role-name>myuser</role-name>
<role-name>??</role-name>
</auth-constraint>

I'm not following your suggestion, as I'm not sure how I would then assign this explicitely to 'no role'


By te way, I'd love to 'RTFM' but I don't have a manual and I can't find anything like what you describe on the web. ;)

[Tim Holloway]

"No Role" would be exactly as I indicated. A role-name entry that has nothing between the begin and end tags.

"TFM" for this stuff is officially defined in the J2EE spec formerly anchored at java.sun.com and now accessed from wherever Oracle decided to base it. If you're a real glutton for punishment, you can also find documentation in the comments in the xsd schema for web.xml.

However, just about any good book on basic servlets/JSPs will have some documentation on how to configure the security parts of web.xml.

You defined 2 roles for the URL pattern /servlet/images/*, "myuser" and "??". The "??" would simply be empty (""). More properly, "myuser" should have been "myrole", since, as I said, user IDs don't apply here. But that would be a conflict or redundancy since all roles and none should match on a "no-role" role.

[Brian Jennings]

I agree it was a poor naming choice. Not mine, but I don't think I should rewrite it at this time. It is what it is unfortunately.

I tried adding a second web-resource-name. MyEclipse flagged it as an error.

I'm limited in what I can access on the internet here at work. I'll try more at home.

Thanks for all your help.

[Brian Jennings]

I found a wayt o get this to work. Google at home provided much more results!

The login page still has broken images, but at least I can log in now, and successfully display our main page.

http://unmaintainable.wordpress.com/2011/04/17/excluding-pages-from-auth/


<security-constraint>
<web-resource-collection>
<web-resource-name>Private</web-resource-name>
<description>Matches all pages.</description>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>authenticated-user</role-name>
</auth-constraint>
</security-constraint>
<security-constraint>
<web-resource-collection>
<web-resource-name>Public</web-resource-name>
<description>Matches a few special pages.</description>
<url-pattern>/index.jsp</url-pattern>
<url-pattern>/login.jsp</url-pattern>
<url-pattern>/public/*</url-pattern>
</web-resource-collection>
<!-- No auth-constraint means everybody has access! –>
</security-constraint>
<security-role>
<description> A role for all authenticated ("logged in") users. This role must be present in the servlet container's user management database. </description>
<role-name>authenticated-user</role-name>
</security-role><login-config>
<auth-method>DIGEST</auth-method>
<realm-name>My Webapp</realm-name>
</login-config>

[Tim Holloway]

Well, since I don't have constraints on access to professional materials here, I cheated and read the manual. Here's a snippet from the XSD:

The auth-constraintType indicates the user roles that
should be permitted access to this resource
collection. The role-name used here must either correspond
to the role-name of one of the security-role elements
defined for this web application, or be the specially
reserved role-name "*" that is a compact syntax for
indicating all roles in the web application. If both "*"
and rolenames appear, the container interprets this as all
roles. If no roles are defined, no user is allowed access
to the portion of the web application described by the
containing security-constraint. The container matches
role names case sensitively when determining access.

So in other words, on the URL patterns for images, scripts, and so forth, you should be able to use

<role-name>*</role-name>