Error message

Deprecated function: The each() function is deprecated. This message will be suppressed on further calls in menu_set_active_trail() (line 2396 of /home/cxdevelo/public_html/includes/

SAML Knowledge Roundup


RightNow + SAML is a pain, impossible to debug, but possible to do. The following is a running collection of tips and knowledge around implementing SAML in RightNow

General SAML

  • The Cert usages on your signing cert seem to matter. I was never certain which usages were required by RN, but it did seem to play a factor.
  • When uploading a Cert file to the server, the file extension is important. The type of extension you use is important depending on if it's DER encoded or PEM encoded. If it's PEM the extension needs to be .pem. If it's DER, the extension must be .crt.
  • The SAML assertion should not contain an InResponseTo tag. Even if it's empty, it's presence causes an error. Thanks Artin for finding this one.
  • Check the values of these config keys: AGENT_SAML20_SSO_ENABLED, CONTACT_SAML20_SSO_ENABLED. Depending on if you are doing Agent or Customer Portal SAML, they will need to be enabled. Also, HTTPS must be enabled. SEC_END_USER_HTTPS or SEC_ADMIN_HTTPS
  • When setting the SAML_20_SIGN_CERTS config with multiple thumbprints be sure there is no non-visible whitespace between your comma and subsequent thumbprints. I once edited my thumbprint list in notepad++ and the resulting copy-paste contained some hidden whitespace. Most likely this was because notepad++ was in Windows line ending mode while RightNow's server is a *NIX environment. Carefully use the arrow keys to step through each thumbprint characters. If there is a double-tap necessary to visibly advance the cursor, you probably have a non-visible whitespace. Delete the whitespace(s), save the config, and cross your fingers

Agent Specific SAML

Customer Portal Specific SAML

  • The contact you are trying to authenticate must have a populated "Login" field; even if you are using a different field as your SAML subject to identify the contact

Do you have any helpful tips? Post it as a comment below.

Categories : 


I just recently ran into a product defect regarding the SAML_20_SIGN_CERTS config setting in August 2013 version. The "ANY-TRUSTED" config value, which is described in the configuration setting description as allowing any certs to be used for SAML login, which is handy for testing:

"Identifies the only certificate(s) (a comma-separated list of SHA-1 hex thumbprints) that are accepted for SAML 2.0 signatures. The special value of "ANY-TRUSTED" may be used to accept any certificate that is trusted by the root CAs for the site. If the ANY-TRUSTED setting is used it is highly recommended that the USE_KNOWN_ROOT_CAS setting be disabled for security reasons. Default is blank."

This value simply DOES NOT WORK in the August 2013 version, so you will have to explicitly set the thumbprint. See the SAML Helpers article for a nice walk-through for testing SAML.

Hey Andy,

Could you speak to the SAML Subject a bit? From your description it sounds like this is what we should be using as the key identifier to a contact in the RNT database. Is this correct?


Hi guys,
I'm trying to configurate RightNow + SAML but without success. Some questions:

- IdP is ADFS 2.0, Are there any good advice/practice for successfully generate the SAML assertion?

- RightNow version is may 2013. We're using a .PEM certificate. and thumbprint =" 42 50 31 df 4c 07 ed 7a 87 7f d1 fd 7d f4 56 f4 f2 fc 63 be", Is it necessary to remove whitespace and / or convert the letters to uppercase? (recommended in the post SAML Helpers)

Finally, we are continually getting the error 17: "SSO_CONTACT_TOKEN_VALIDATE_FAILED"


Hi we r using self signed certificate and uploaded to console under 'additional root certificates'.
We have set up contact with login also set a password. configss are also in place . not sure what is going wrong getting error code 18:(
any issues with self signed certifictaes?

Sorry for the really, really late reply. I must have missed this message back in April.

here is no issue with self signed certs.
A couple things to check:
- For the "SAML_20_SIGN_CERTS" setting, make sure you use upper case characters when specifying the thumbprint
- If the cert is self-signed and root, upload it both to the 'additional root certificates' and 'intermediate certificates' folders.

I am using self signed certs and uploded the certificate to RN and added thethumbprint to SAML_20_SIGN_CERTS.
But i am not locate AGENT_SAML20_SSO_ENABLED, CONTACT_SAML20_SSO_ENABLED parameter.

Please let me know how to enable above two Parameter.


Those are both "hidden" configs that can only be set by Oracle Customer Care. You'll have to submit a support ticket to ensure they are enabled.

Chances are that they are already enabled.

Hi Andy, hope you are well. I've just tried to configure SSO by importing metadata provided by the IdP. Then generated/exported the metadata from Oracle Service Cloud (OSvC) and given to the IdP. He came back saying that he wasn't able to import the metadata file. It fails to process the file, and he says that the reason is that there is characters such as ‘+’ in the entityID. My understanding is that the entityID is generated by OSvC. So I'm not too sure on how to deal with it. Appreciate your insight.

Good round-up. A couple thoughts:

1. The non-visible whitespace for thumbprints almost always comes from people opening up the certificate details in Windows built-in certificate viewer, and then copying the thumbprint from there. There's hidden whitespace in that viewer. If I ever copy from the certificate viewer, I just paste into Notepad first, then remove all the whitespace, and copy that result from Notepad.

2. Another "gotcha" I've seen recently is multiple certificates that have the same common name (CN). Even if they are technically different certificates, the system doesn't seem to like certificates that share the same CN, and it will usually only read the first one it finds, so if you have an old and a new certificate with the same CN in your Additional root certificates folder, for example, there's a decent chance that the system won't be able to validate the assertions using the new certificate until you remove the old one.

Hi John,
Thanks for the tips

1. I found the exact same thing! My solution though is to just use my Mac (although your solution is more feasible for the Windows crowd).

2. I too have seen this problem but when I encountered it there was a fundamental OSvC issue that caused the dupes to occur. The particular client had secure email enabled on their site; from what I recall, OSvC copied certs received through the SME emails into the server's cert folders. Their particular cert set-up had issues with duplicate CN names. The net result was that one day unexpectedly SSO stopped working and I got to spend the day figuring out what the heck happened. It took removing the duplicate cert (that came from the email functionality) to the SSO working again. This was a few years ago so I don't know if it is still a platform issue or if the development team resolved the root cause.

Zircon - This is a contributing Drupal Theme
Design by WeebPal.