36

I'm implementing a SAML 2.0 Service Provider and need to install a SAML 2.0 Identity Provider for testing. Given this need, the Identity Provider should ideally be free (or have a trial period) and be easy to set up and configure.

I'm looking for basic single sign on and single log out functionality.

I've tried Sun Opensso Enterprise. The price is right, but so far it's been a nightmare to configure. Also, its error messaging and logging leaves a lot to be desired and I'm often troubleshooting an issue that basically boils down to a misconfiguration or a counterintuitive default setting.

mavis
  • 3,100
  • 3
  • 24
  • 32
Steve Reed
  • 2,481
  • 2
  • 20
  • 20

11 Answers11

22

What problems are you having configuring OpenSSO? I found OpenSSO to be the easiest setup!

My notes on getting the basic IDP up and running are below - hopefully they help you get up and running.

Michael

I've found that the best (i.e. most painless) way is...

  1. Use Glassfish - this is a well supported container for OpenSSO - use the developer profile to make your life even easier - use the quick setup steps as documented on the download page
  2. Deploy OpenSSO as per the basic instructions (unpack the zip - deploy the war file to the default domain)

I've used the following as my setup steps (I use OpenSSO build 7):

  • Under "Custom Configuration", click "Create New Configuration".
  • Type the password "adminadmin" in the Password and Confirm fields. Click Next.
  • In Server Settings, leave the defaults alone (or edit if if needed) and choose Next.
  • In Configuration Data Store, leave the defaults alone (or edit if needed) and choose Next.
  • In User Data Store, choose "OpenSSO User Data Store". Click Next.
  • In Site Configuration, choose No (this installation will not use a load balancer). Click Next.
  • In Default Agent User, enter admin123 as the password and confirmed password. Click Next.
  • Click "Create Configuration".
  • Click "Proceed to Login".
  • Log in as "amadmin" with the password "adminadmin".

The instructions above are based on http://developers.sun.com/identity/reference/techart/opensso-glassfish.html

You've now got your basics up and running. Create a subrealm under / called users, and create an account or two in there.

Now prep your SP metadata. Don't put too much in your metadata to start with - keep it simple.

In the default page of the GUI, choose to create a hosted IDP. This is a pretty basic workflow. You should specify your /users realm and choose to use the test key alias for signing. The circle of trust you create can be called petty much anything.

When you complete the workflow you'll be asked if you want to import metadata for an SP - say yes and choose to import from your prepared metadata file.

At this stage you should be pretty much set up.

You'll want to grab your IDP metadata next. There are a few ways to do this. You could use "http://servername:8080/opensso/ssoadm.jsp?cmd=export-entity" or "http://servername:8080/opensso/saml2/jsp/exportmetadata.jsp?realm=/users".

... and that's pretty much it for setup.

If you run into issues interoperating with OpenSSO you can look in the OpenSSO data directory (~/opensso by default). There's debugging and logging information in the subdirectories under there. You can cross reference that information with the OpenSSO Wiki, which has some pretty good troubleshooting information.

Michael van der Westhuizen
  • 774
  • 7
  • 12
  • I guess my biggest problems with OpenSSO so far have either been with accepting my SP metadata or in my inability to track down the root of authentication failures when they happen. On the first, OpenSSO has complained about elements in my metadata that should be ok but it doesn't expect. SingleLogoutService and some other Organization metadata for example. I'll check out the logs in ~/opensso and the wiki as well. Thanks for that. – Steve Reed Jul 14 '09 at 17:34
  • Hi Steve, You should be able to go to http://servername:8080/amserver/Debug.jsp to bump up debug levels if you're not finding enough information under ~/opensso. I had quite a few metadata problems too - that's why I suggested starting (very) simply. Once I got my head around what the metadata and the configs in OpenSSO were supposed to look like things started making a lot more sense. – Michael van der Westhuizen Jul 14 '09 at 17:51
  • 1
    Have you sought help on the OpenSSO mailing list, Steve? To subscribe: 1. Go to https://www.dev.java.net/servlets/Join and register for a java.net account. 2. Go to https://opensso.dev.java.net/servlets/ProjectMembershipRequest and request 'Observer' role on OpenSSO. 3. Go to https://opensso.dev.java.net/servlets/ProjectMailingListList and subscribe to 'users@opensso.dev.java.net'. – metadaddy Jul 15 '09 at 07:14
  • 10
    The OpenSSO project has become OpenAM. Since this page is relatively high up on several Google searches I did recently, I figured I would make a note. – Summers Pittman Dec 08 '11 at 21:16
  • 1
    OpenSSO is out but steps above can be used for mentioned OpenAM without any problems (I just needed to use second link for the metadata export, first one did not worked). Thanks for the great tutorial! – xMort Oct 05 '15 at 13:26
13

Instead of installing and configuring an IdP you can use a hosted test platform such as TestShib or OpenIdP. Both work along the same lines but OpenIdP requires you to register.

  1. Generate your SAML metadata XML file.
  2. Register your SP with the IdP by uploading your metadata XML file.
  3. Register the IdP with your SP by downloading their metadata XML file.
Tamlyn
  • 22,122
  • 12
  • 111
  • 127
  • I think that gets me soooo close, if I could just figure out what to use for the entity id at OpenIdP. – tggagne Mar 27 '14 at 23:27
  • Or if I could figure out the final assertion and get around, "unable to map the subject to a Salesforce.com user." – tggagne Mar 28 '14 at 00:36
  • Or you can use Centrify IDP for testing, register here: https://www.centrify.com/cloud/cloud-service-registration.asp; get yourself a tenant which is FREE, you can then create few users, add an generic App (https://cloud.centrify.com/vfslow/lib/docs//appref/wwhelp/wwhimpl/js/html/wwhelp.htm#href=saas_appref_generic_SAML.html) which you can tie it to your SP and test it away. – Sumana Mehta Apr 24 '14 at 22:14
  • OpenIdP No longer works: "Important The OpenIdP has been shut down. It is no longer possible to use it to test your SAML Service Provider. If you were using it for that purpose, you will need to look for alternatives." – Rob Audenaerde Sep 22 '16 at 08:05
7

Use samlidp.io, it is perfect and free for testing, you can setup your own IdP with a few clicks with adding your custom SP's metadata and that's all, it works.

sitya
  • 79
  • 1
  • 1
2

You can configure Auth0 as a SAML IdP. The setup is straight-forward and there's a free tier available.

thameera
  • 9,168
  • 9
  • 37
  • 38
2

You can give a try to LemonLDAP::NG (http://lemonldap-ng.org)

It is packaged for most Linux distributions, so easy to install and to set up.

Clément OUDOT
  • 31
  • 1
2

I'm using Keycloak (https://www.keycloak.org/).

  • Open Source
  • Standalone application
  • Easy to configure
Mr. BoFrost
  • 103
  • 7
1

Online services for test IDP/SP SAML 2.0:

Omid Raha
  • 9,862
  • 1
  • 60
  • 64
0

I would recommend to use OpenAm https://backstage.forgerock.com/#!/downloads/OpenAM/OpenAM%20Enterprise#browse to istall locally on tomcat instance. It's quite easy to setup and get it up and running during a couple of hours.

Nick Prusov
  • 146
  • 7
0

I have been struggling with testing SAML2 integration for a long time, and used OpenSSO. Since I discovered OKTA for testing applications http://okta.com/ I haven't looked back. It is perfect, easy to use, and you can also create different users and send custom attributes back to the SP.

OpenSSO is not nice. For start you have those ridiculous captchas which don't even make sense. SSOCircle does not allow you to send custom attributes, it does not allow you to use SHA-256 encryption either, for what I've seen. OpenSSO does not give you any help about error messages unless you pay for their debug functionality (which is probably poor given the rest of the application works poorly).

nuvio
  • 2,555
  • 4
  • 32
  • 58
0

Take a look at this answer.

In a nut shell, samling is a serverless SAML IdP for the purpose if testing any SAML SP endpoint. It supports AuthnRequest and LogoutRequest. It runs solely in the browser to simulate SAML responses returned from a SAML IdP - no registration, no servers, just a browser, allowing you to control many aspects of the response - from success to various failures.

fujifish
  • 951
  • 10
  • 10
0

For testing Mock SAML or SAMLTest are good options to get started. Also Okta with their free developer account.

Deepak Prabhakara
  • 1