Installing OpenAM Release 9 on Tomcat 6.0.26 on Windows 7

So Oracle have moved away from Sun Access Manager towards the Oracle Access Manager roadmap. However, ForgeRock have taken over the product (only possible because of the Opensource nature of the product).

Anyways, let’s push on with installing OpenAM Release 9 onto Tomcat 6.0.26 on Windows 7.

Update – Check out:

for an install video.

First of all, download yourself a copy of Tomcat 6.0.26. Next, head over to the downloads page on ForgeRock and grab a copy of OpenAM.

To set up Tomcat, extract it to a folder. I picked C:\tomcat. We’ll need to edit C:\tomcat\bin\startup.bat and change the amount of memory available for Tomcat.  Add the line set CATALINA_OPTS=”-Xmx1024m” above the set “CURRENT_DIR=%cd%” line. This sets the maximum memory available to Tomcat as 1024MB. You’ll probably have to tell Tomcat where to find the Java Runtime Environment.

Click Start and right click on the Computer button and select properties. Then click Advanced System Settings. Finally click Environment Variables. Click the button for a new System Variable. The variable is called JRE_HOME and the value in my case is c:\Program Files\Java\jre6\.

We’ll need to add an administration user. Edit C:\tomcat\conf\tomcat-users.xml.

Add the following lines:

<role rolename=”manager” />
<user username=”admin” password=”admin” roles=”manager” />

Awesome. Now edit c:\windows\system32\drivers\etc\hosts in Notepad as a privileged user. Add a domain and your computer’s IP address. I added:

sso.kenningcorp.com 10.1.1.3

Now open up the command line and navigate to C:\tomcat\bin. Type startup and Tomcat should start. If things are going well, you should see this window. The last line should mention the server startup in X ms.

In your web browser, head to http://sso.kenningcorp.com:8080, obvious replacing my domain with your domain. You should see the Tomcat page if things are going well. Now navigate to http://sso.kenningcorp.com:8080/manager/html, with the login being admin and the password admin.

Under WAR file to deploy navigate to openam_release9_20100207\opensso\deployable-war and select opensso.war. Then hit the Deploy button. It’ll take a while as the war file is uploaded through your browser into Tomcat. Tomcat has an auto-deploy function, Google it if you’re interested.

Eventually the application will be deployed. Navigate to http://sso.kenningcorp.com:8080/opensso.

If things are going well, you should see the OpenSSO configuration options page.

Click Custom Configuration. Here are the settings I use:

  1. Default user password – password
  2. Server settings – I leave the default entries in there
  3. Configuration store – First instance, OpenSSO
  4. User data store – OpenSSO
  5. Site configuration – No (not being a load balancer)
  6. Default policy agent password – password2

Now click Create Configuration. Fingers crossed. I’ve had problems installing this, in the following order:

  1. Don’t use the version of Tomcat that comes with XAMPP. Didn’t work for me.
  2. Don’t use the nightly version of OpenAM. Didn’t work for me.
  3. Don’t use 127.0.0.1 as the IP address of your domain. Didn’t work for me.

I had weird errors such as cookie domains not being valid host names, and other weird errors.

If things go well it should install. I get an error about a log file being NULL, but I don’t worry about it. Head to http://sso.kenningcorp.com:8080/opensso, which should now redirect you to http://sso.kenningcorp.com:8080/opensso/UI/Login. Type amAdmin as the username, and password as the password, and you should be authenticated against your OpenAM install, and shown the Administration page. Congratulations!

Certificate Not Trusted error with SimpleSAMLPhp

I’ve just received an email stating:

I have different certficates in the simplesamlphp sp and OpenSSO IdP, but both certificates signed by same CA.

If we have metadata signing enabled in the simplesamlsp, and If I try to “Register Remote Identity Provider”, I am getting the erro, “Certificate Not Trusted”

Can’t we use different certificates signed by same CA in simpleamlphp and opensso ?

So we have a:

  1. SimpleSAMLPhp SAML2 Service Provider (SP)
  2. OpenSSO SAML2 Identity Provider (IDP)

So if this is the case, why would you be trying to register a remote identity provider in OpenSSO? You should be:

  1. Creating an IDP on OpenSSO
  2. Grabbing that IDP metadata (including the signing information)
  3. Creating a SP on SimpleSAMLPhp
  4. Adding the IDP’s metadata to SimpleSAMLPhp (idp-20-remote.php off the top of my head, don’t forget to convert it into the SimpleSAMLPhp format)
  5. Adding the SP’s metadata URL to the IDP.

http://kenning.co.nz/identity-management/connecting-opensso-idp-with-simplesamlphp-sp/ tells you a little more about connecting an OpenSSO IDP to a SimpleSAMLPhp SP.

Connecting OpenSSO IDP with SimpleSAMLphp SP

Giving OpenSSO a go? I recommend OpenSSO Enterprise 8.0. For the web container, Glassfish Enterprise V2.1 seems to work well for me.

I had various problems with OpenSSO Express 7 and Glassfish V3 Prelude. Your luck may vary here.

If you are deploying OpenSSO on Glassfish, don’t forget to change the following JVM settings:

  1. -client to -server
  2. -Xmx512m to -Xmx1024m
  3. I had various problems logging in and getting redirected to the login page. Try adding -Dcom.iplanet.am.cookie.c66Encode=true to your JVM settings

Next, deploy OpenSSO. I normally deploy to /opensso, but that’s just me.

After deploying configure OpenSSO. I normally pick Custom configuration, and for the purpose of this Demo, I install both the configuration and user information into the inbuilt data store. Finish configuration and log in.

Next head to Create Hosted Identity Provider. Leave all the settings default except change the signing key to Test. Give your Circle of Trust a name. Under attribute mapping, I normally enter cn=cn. We can add other settings, and it’s better to have a SAML assertion with something in it (since SimpleSAMLphp will reject empty assertions).

Install SimpleSAMLphp as a SP. Once set up you should be able to go to:

http://webserver/simplesaml/saml2/sp/metadata.php

And have your SP metadata.

In OpenSSO click Register Remote Identity Provider. Enter the URL above in the box for the metadata URL in OpenSSO. Select the circle of trust to add this to. Click configure.

Next go to:

http://webserver/opensso/saml2/jsp/exportmetadata.jsp

And copy that XML. Head to:

http://webserver/simplesaml/admin/metadata-converter.php

And paste the OpenSSO IDP metadata into that box and click Parse.

Take the result and copy into:

<simpleSAMLphp>\metadata\saml20-idp-remote.php

You’ll have to change the top line from:

'http://webserver/opensso' => array (

To:

$metadata['http://webserver/opensso'] = array (

And don’t forget to change the comma at the end of the block you just pasted into a semicolon. Save saml20-idp-remote.php.

Head back to OpenSSO. Click the Test Federation Connectivity link. Select your circle of trust. Click Start Test. You can use the username “demo” and the password “changeit”.

The test should work correctly. If it does you’ve got SAML connectivity between an OpenSSO IDP and a SimpleSAMLphp SP.

Some things could go wrong though, so we need to think about what’s happening here:

  1. Is the OpenSSO IDP configured correctly?
  2. Is the SimpleSAMLphp SP configured correctly?
  3. Does the OpenSSO IDP trust the SimpleSAMLphp SP?
  4. Does the SimpleSAMLphp SP trust the OpenSSO IDP?

The problem is one of those four things. Good luck.

Sun GlassFish Enterprise Server v3 Prelude – A first glance

I’m a big fan of Tomcat. It’s sweet. It’s pretty quick. A little lightweight on administration, but fairly simple to install (extract the zip), and Bob’s your father’s brother.

So Sun’s been working on application servers for quite some time now, and the latest incarnation is Glassfish. This article reviews GlassFish Enterprise Server v3 Prelude.

One of the great things about Sun’s software model is that the software is a free download. This is understandable because you really won’t get that far without Sun support in a production-like environment. First point of call is to download Glassfish.

It’s a pretty light download, 27Mb for the English Windows version.

Installing is a snap, just double click on the installer. You’ll need a Java JDK. If you’re doing any enterprise stuff with Sun products you’ll probably need a Java JDK.

The installer lets you pick the ports for the admin interface (4848 by default) and the http port (8080 by default). The interface neatly checks to see if those ports are free, and warns you if they’re not. You can choose to pick a username and password for the admin interface, or leave it as anonymous.

The rest of the installation went smoothly. After installation you have the option to fire up the server. Next port of call is heading to the admin interface (http://localhost:4848). There’s a bit of a delay while Glassfish installs the admin application on the server, but then you’re at the GUI admin screen.

There’s no way to restart the server from the GUI screen. You’ll need to head to the command line and type:

asadmin stop-domain

asadmin start-domain

I’m sure there are other methods of restarting the application server, but that’s what I’ve been doing. If you leave the domain off the command, it’ll default to domain1.

If you’re used to the Tomcat’s admin interface (which is sparse), then you’ll be in for a treat with Glassfish. It’s deep. There’s a lot to look at.

At only 27Mb, it’s a quick download. Give it a go and see how you feel.

OpenSSO Enterprise 8.0 doesn’t log in correctly – the fix

Hi there,

If you’ve installed OpenSSO Enterprise 8.0 on Glassfish, you may have the following problem:

  • After installation of OpenSSO, you try and login.
  • Using the correct username and password you are redirected back to the login screen.

The fix is to add the line

-Dcom.iplanet.am.cookie.c66Encode=true

As a JVM option in Glassfish, when changing the other JVM options (like -client to -server).

Source: Sun.com.

End-to-end Identity Management with open source?

After working with a relatively large identity and access management implementation over the last year, I’m really interested to continue working in this field.

There are with large projects many lessons learned, and plenty of times when you think to yourself “could I have done this better?”

And so, I’m contemplating getting into the Identity Management business.

But before I do, there seems to be a few different paths to take:

Each of decisions has their own pros and cons, so lets explore those.

First, supporting Oracle. Big organisations need heavy identity solutions. They have many different providers of identity data, and many different services that consume that data. While the organisation owns that identity data, they don’t have much control over where that data is stored and consumed. Hence the need for lots of different agents to interact between identity provider <> identity consumer. And that’s all well and good, but the competition for providing support in this space is fairly niche. You must be big enough to support the product, and to find customers big enough to want the product. In New Zealand, this is a fairly limited market, and is owned, unsurprisingly, by Oracle.

Next, there’s supporting the Sun identity stack. I have lots of experience on the Sun identity stack, and it has its benefits and pitfalls. The main difference between the Sun stack and the Oracle stack is open is open source (Sun) and one is not (Oracle). For customers this means not paying Sun for the software, but to implement something so significantly complex, you really must have a smart consulting company on your side, like Sun. The same arguements about being heavyweight apply here too. Only certain large organisations need this highly complex solution.

Next there’s the middleweight solution, Triplesec. Triplesec provides a lot of the functionality of the heavyweight solutions, but underpinned on relatively less complex architecture. The pitfall I’m finding with Triplesec is a lack of documentation. One advantage (or disadvantage) of the heavyweight solutions is documentation, lots and relatively thorough. Triplesec technologically is sound, but without documentation or support, you’d have to have a lot of trust in your vendor to be implementing this at the moment. Also to my knowledge, this solution is relatively untested – I haven’t heard of any large scale implementations. Not that this should stop you, but just be warned that you’re on your own here.

Finally, there’s SimpleSAMLphp. This isn’t a whole identity management solution as provided by Oracle or Sun, but more a way to take information from an Identity Source like an LDAP directory, and then authenticate against that. Provisioning new users and managing multiple disparate identity sources into one meta-identity provider this is not, but for a simple identity solution that is relatively easy to understand, support, and is widely in use (throughout all of Norway and Denmark), pretty bespoke, and using open standards. A good solution for the majority of small New Zealand companies.

And for some fun, I’ve been working on a logo for this project:

Identity Systems

The problem with Policy Agents + SAML and Access Manager using SimpleSAMLphp

Policy Agents are good and bad when it comes to Access Managers and Identity Management. The good:

  • The clients tend not to have to add all this authentication code to their application

And the bad:

  • The clients tend to have to install a Policy Agent on their infrastructure.

This part can be a problem. Policy Agents do not support all platforms, and of the ones they do support, I’ve found their implementation of features to be of a … variable quality.

So we’ve got clients who use flavours of linux with flavours of web servers, including ones which may never be supported. So what do we do?

Well we’re piloting building a machine with simpleSAMLphp as an IDP, and then protecting that machine with a Policy Agent. Then at the other end, any web server that runs PHP can run simpleSAMLphp as a SP.

So when someone accesses the SP, they click the link to login, an assertion is sent to the IDP, the policy agent intercepts this request and forces the user to authenticate against the Access Manager, then injects the user’s information back into the request, which the IDP inserts back into the SAML assertion which the SP receives.

This loose coupling of OpenSSO + simpleSAMLphp is talked more about at Sun’s website.