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.

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.