Tuesday Apr 28, 2009

New and Updated Policy Agents for OpenSSO

We released four new 'version 3.0' policy agents for OpenSSO today:

These join the existing version 3.0 policy agents for Sun Glassfish Enterprise Server (formerly known as Sun Java System Application Server) 8.x/9.x (documentation, download) and Oracle/BEA WebLogic Server/Portal 10 (documentation, download). While the 3.0 agents add centralized configuration and some other features, it's important to note that all of the version 2.2 agents are tested and supported with OpenSSO.

Friday Mar 27, 2009

OpenSSO Tab Sweep - Mar 27 2009

As always, a bumper crop of OpenSSO news from the last couple of weeks...

That wraps things up for another week - I'm off to jump in the Patmobile and brave 101. See you next time!

Wednesday Jun 13, 2007

Xalan gotcha with OpenSSO on Tomcat on Ubuntu Feisty

I've been meaning to blog about this for a while, but haven't been able to scrape together a few minutes. Anyway, if you've been reading Superpatterns for a while you'll know that I use Tomcat on Ubuntu to run OpenSSO. I wrote a little while ago about some problems with Tomcat in Ubuntu 7.04 'Feisty Fawn' - Ubuntu hanging at startup due to issues with catalina.out and security policy needing to be updated due to a change in where Tomcat keeps web applications on disk.

Another issue I've seen is the following stack trace when parsing XML:

javax.xml.transform.TransformerFactoryConfigurationError: Provider org.apache.xalan.processor.TransformerFactoryImpl not found
	javax.xml.transform.TransformerFactory.newInstance(TransformerFactory.java:119)
	com.sun.identity.shared.xml.XMLUtils.print(XMLUtils.java:674)
	com.sun.identity.saml.assertion.Assertion.parseAssertionElement(Assertion.java:191)
	com.sun.identity.saml.assertion.Assertion.(Assertion.java:147)
	com.sun.identity.wsfederation.profile.RequestSecurityTokenResponse.(RequestSecurityTokenResponse.java:131)
	com.sun.identity.wsfederation.profile.RequestSecurityTokenResponse.parseXML(RequestSecurityTokenResponse.java:62)
	com.sun.identity.wsfederation.servlet.RPSigninResponse.process(RPSigninResponse.java:93)
	com.sun.identity.wsfederation.servlet.WSFederationServlet.doPost(WSFederationServlet.java:143)
	javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
	[...]

A quick Google turns up this blog entry from Andrew Beacock in the UK. The issue is that, previously, Xalan was included in JDK 1.4, but since then, the Apache community has chosen XSLTC as the default processor for developing XSLT 2.0, and JDK 1.5 followed suit for JAXP 1.3. I'm running Tomcat on Sun's 1.5.0_11-b03 JVM, hence the missing TransformerFactoryImpl. The bottom line is this: grab Xalan for yourself and put it in your web app's WEB-INF/lib directory.

If you're working with OpenSSO, you can just copy xalan.jar, xercesImpl.jar, xml-apis.jar and serializer.jar from Xalan to opensso/products/extlib, rebuild the OpenSSO WAR and you should be good to go.

And, again, before anyone asks "Why aren't you using Glassfish?" - I am, I'm just using Tomcat as well, since a lot of the OpenSSO contributors use it. Their pain is my pain

Thursday May 03, 2007

Tomcat on Ubuntu Feisty

A while ago, I blogged about running OpenSSO on Tomcat in Ubuntu. I recently upgraded Ubuntu to 7.04 'Feisty Fawn', which, while most things work great, seems to have caused some issues with Tomcat...

The first is this bug - when you start Tomcat, it just hangs. Apparently it's to do with /var/lib/tomcat5.5/logs/catalina.out being a named pipe. The workaround that works for me is to add the following line (shown in bold) to the start block in /etc/init.d/tomcat5.5

                $DAEMON -user "$TOMCAT5_USER" -cp "$JSVC_CLASSPATH" \\
                    -outfile "$LOGFILE"  -errfile '&1' \\
                    -pidfile "$CATALINA_PID" $JAVA_OPTS "$BOOTSTRAP_CLASS"
                cat /var/log/tomcat5.5/catalina.out > /dev/null &
        else
                log_progress_msg "(already running)"
        fi

The second issue is that Tomcat seems to have changed where it puts its web applications. They were in /usr/share/tomcat5.5/webapps; they are now in /var/lib/tomcat5.5/webapps. This breaks the security policy I blogged about last time - you now need to add the following to /etc/tomcat5.5/policy.d/50user.policy:

grant codeBase "file:${catalina.base}/webapps/openfm/-" {
  permission java.security.AllPermission;
};

(i.e. switch from ${catalina.home} to ${catalina.base})

And before anyone asks "Why aren't you using Glassfish?" - I am, I'm just using Tomcat as well, since a lot of the OpenSSO contributors use it. Their pain is my pain

Friday Nov 10, 2006

OpenSSO on Tomcat in Ubuntu

The 'single WAR' deployment of OpenSSO allows you to simply deploy a WAR file into a web container such as Glassfish or Tomcat. The first time you hit the OpenSSO URL, a configurator runs, collecting some basic parameters, saving them to configuration files and setting up OpenSSO for use. You can save this configuration anywhere in the file system; the configurator saves that location in a file in the home directory of user as which the web container is running (that's a really clumsy way to put it, but hopefully the meaning is almost clear).

Numerous folks are deploying OpenSSO on Tomcat. In a typical 'developer' installation, where you run Tomcat from the command line, all works well - you get a file named something like AMConfig_localhost_opensso_ in your home directory. AMConfig is a constant prefix and _localhost_opensso_ is OpenSSO's deployment location (/localhost/opensso/) with slashes replaced by underscores. Ubuntu installs Tomcat on 'localhost', and I deployed the OpenSSO war file into /opensso, so I get a file called AMConfig_localhost_opensso_ whose content is simply the path to the main configuration data. Your mileage will vary!

Now - I'm running Ubuntu on my laptop, with the default Ubuntu distribution of Tomcat 5.5. The first time I tried to deploy OpenSSO it failed - looking at Tomcat's logs, I could see

localhost_2006-11-03.log:java.security.AccessControlException: access denied (java.util.PropertyPermission user.home read)

Tomcat is running with the Security Manager and is denying access to the user.home property. From previous experience, the quickest way round this (short of completely disabling the security manager) is to grant your web application all rights. I added the following to /etc/tomcat5.5/policy.d/99examples.policy:

grant codeBase "file:${catalina.home}/webapps/opensso/-" {
  permission java.security.AllPermission;
};

You could, of course, specify much more granular permissions, but this gets you going with the minimum fuss.

So - try again. This time, OpenSSO gets a little further, but fails again with

java.io.FileNotFoundException: /usr/share/tomcat5.5/AMConfig_localhost_opensso_ (Permission denied)

Although OpenSSO can now locate the user's home directory, it can't actually write to a file there, since, in this configuration, Tomcat is running as the tomcat5 user, whose home directory (/usr/share/tomcat5.5) is owned by root and is not writable by tomcat5. One solution is to temporarily make that directory writable by all (sudo chmod 777 /usr/share/tomcat5.5), flipping it back after OpenSSO configures itself successfully (sudo chmod 755 /usr/share/tomcat5.5). A more elegant approach, and one which doesn't require you to go back and tidy up, is to do

sudo touch /usr/share/tomcat5.5/AMConfig_localhost_opensso_
sudo chown tomcat5 /usr/share/tomcat5.5/AMConfig_localhost_opensso_

Now, you just need to ensure that you give the configurator a directory that is writable by tomcat5 and all is well - a working OpenSSO and an interesting excursion through the mechanisms that Tomcat and Ubuntu use to prevent web applications from running arbitrary code.

About

superpat

Search

Archives
« April 2014
MonTueWedThuFriSatSun
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Today