How to test SAML SSO to my site?

gdemaria used Ask the Experts™
I am trying to implement single sign-on using SAML 2  with a connection TO my website.

That is, when a user logs into their company website ( for example), then will click a link to automatically log into our site.

Without troubling one of my clients as a guinea pig, how can I test the integration to my site?  

I was thinking about getting a wordPress site with a SAML plug-in to try it out, but I have never done that either.

Any information on testing SAML or using wordpress greatly appreciated.

We are using okta for our authorization
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
To implement SAML, you need to understand SSL certificates.

Basically, the most common way that SAML works is that has an application called an identity provider. Users log into the identity provider at and then click on a link inside the identity provider which kicks off a process to try to log them into YOUR website (let's say it's

So when that process starts:
1. The identity provider creates a medium-sized chunk of XML that is called an assertion. The assertion simply says, "User John Smith is coming from and wants to log into" So an assertion is sort of like a ticket that you might buy to get into some event, like a concert.

2. The identity provider uses a private key (this is where understanding SSL certificates comes into the picture) to add a digital signature to the assertion. This digital signature is based off of the content of that ticket and it ensures two things:
- That the assertion was generated by the identity provider (that it wasn't forged by someone else)
- That the assertion content has not been manipulated. If the content changes, then the signature won't match the content.
So this digital signature is sort of like having a valid bar code on that ticket I mentioned earlier. Someone trying to forge a ticket won't have a valid bar code, so their fake ticket won't be recognized as valid.

3. The identity provider takes the digitally-signed assertion, base64-encodes it, and then usually generates a web page with a hidden form that immediately and automatically submits itself. That way, the end user's browser is technically the one that is submitting the form. Okta will generate that intermediate "logging in" grey page so that users have something visually pleasing to look at while this all happens.

4. YOUR website,, has some page like "saml_login.php" or something that is the target of that form, so it receives the POSTed assertion from the end user's browser.

5. That saml_login.php (or whatever you call it), has to base64-decode the assertion (the variable is usually called "SAMLResponse") to get to the XML. Then it needs to parse that XML (easiest way is to use the SimpleXML or DOMDocument extensions in PHP) to get the signature and then validate that the signature matches the rest of the content. This process gets a little technical and relies on a process called C14N that looks at a specially-formatted version of the content. In order to VALIDATE the signature, you need the corresponding PUBLIC KEY. (So a quick recap - private key CREATES the signature, and the corresponding public key VERIFIES the signature)

That means that you have to get the public key from and store it somewhere on your server so that you can load it up and use it to verify the data. You would use the OpenSSL extension from PHP to load the public key, and openssl_verify() to verify the signature against the C14N content.

By doing this, you are ensuring that you are only accepting assertions that have come from's identity provider, and only accepting assertions that have not been tampered with.

Ideally you will also implement code that checks the timestamps in the assertion content so that you're rejecting expired assertions, assertions that are already used, etc...

6. Finally, once you've validated the assertion all looks good and everything has passed the security checks, then saml_login.php can safely take the data from the assertion and do whatever you need to do to log the user into your own system (e.g. set cookies or session data or whatever your system uses to log a user in).

All that said, a framework like SimpleSamlPHP will do a lot of this work for you. It's worth noting that the above reflects the most common and simplest way that SAML works, which is called the "POST binding" - there are other ways that SAML can work, too.

However, the premise will still require you to be able to get a public key from (a signing certificate), and store it on your server so that your server knows that it can trust assertions from That is a critical part of the process.

So to get back to your original question - to test out SAML for a specific service provider, you basically need to set up Okta with a new connection to that service provider, and then take the public key / signing certificate for that connection, and ensure that the SAML service provider (your or whatever the site is) can trust that certificate.

Or if Okta is acting as the service provider here, then you need to set up a small SAML application (again, SimpleSamlPHP is a decent choice for a quick setup) that will generate signed assertions that will be sent over to your Okta endpoint (called the Assertion Consumer Service URL or ACS for short).
gr8gonzo  - thank you so very much for this thoughtful explanation.  I found it extremely helpful and copied it and shared it with my team.   My neglect of the question does not represent how very helpful and valuable I found the information.  Thank you very much for taking the time to give such a great answer.  My apologies for not getting back to the question.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial