[OPENAM-4195] SAML2token saved in CTS with hex tokenId but read without converting to hex Created: 14/Jul/14  Updated: 20/Nov/16  Resolved: 02/Feb/15

Status: Resolved
Project: OpenAM
Component/s: CTS, SAML
Affects Version/s: 11.0.0
Fix Version/s: 11.0.3, 12.0.1, 13.0.0

Type: Bug Priority: Major
Reporter: Joost Zalmstra [X] (Inactive) Assignee: Peter Major [X] (Inactive)
Resolution: Fixed Votes: 4
Labels: EDISON, release-notes
Remaining Estimate: Not Specified
Time Spent: 6h
Original Estimate: Not Specified

Issue Links:
relates to OPENAM-5614 Jackson can not instantiate AuthnRequ... Resolved
Sprint: Sprint 76 - Sustaining
Support Ticket IDs:


I am trying to use SAML failover. I have setup an external (OpenDJ) CTS and have enables SAML fail over. I have two OpenAM instances behind a load balancer both connecting to the same OpenDJ.

When I login in OpenAM with a SAML assertion with SAMLId of, e.g., 6388b327-58b5-4c85-99f3-5c050bfa76c4 I find it is saved in the CTS with a coreTokenId of 36333838623332372d353862352d346338352d393966332d356330353062666137366334. This is the hex version of the SamlId.

However, when I login with the same SAML assertion on the second OpenAM instance OpenAM reads the CTS with the samlId, without converting it to HEX. It can therefore not find it in CTS and will allow the login.

To be able to keep working I changed (in a local copy) in SAML2CTSPersistentStore.retrieveSAML2Token:

// Retrieve the SAML2 Token from the Repository using the SAML2 Primary Key.
// In the save of the SAML token the key is hex encoded therefore we have
// to do that here too before we try to retrieve it. That it did not
// happen is a bug in OpenAM which we (TomTom) have fixed locally
String encodedKey = new KeyConversion().encodeKey(samlKey);
Token token = persistentStore.read(encodedKey);
SAMLToken samlToken = tokenAdapter.fromToken(token);
return samlToken.getToken();

Comment by Peter Major [X] (Inactive) [ 17/Dec/14 ]

I don't really know where to really start with this issue. There are no reproduction steps in the bug description, and it isn't even clear if OpenAM acts a hosted IdP or SP.
I will try to reproduce this based on intuition, but I would really appreciate a more helpful issue description.

Comment by Joost Zalmstra [X] (Inactive) [ 18/Dec/14 ]

Sorry about that. Here some more information.

I am using an OpenAM configured as SAML2 SP with a CTS connected to it.

I logon to the SP with a valid SAML assertion (from an IdP) and the logon is successful. Next I try to logon with the same SAML assertion to the same SP. This should fail because it is not allowed to use the same assertion multiple times. However, the logon succeeds!

What I found is that on the first logon the SAML assertion is saved in CTS. There the primary key of the assertion is hex encoded before it is written into the CTS. (I can not find the exact place where this is done, since it is a long time since I debugged the issue)

On the second logon OpenAM needs to check if the assertion has been used before. As put in the description this is a setup with multiple OpenAM behind a load balancer. If the second logon takes place on another OpenAM then the first this means that OpenAM looks for the assertion in the CTS. This is done in the method SAML2CTSPersistentStore.retrieveSAML2Token. However, there the primary key is not hex encoded. Therefore the assertion is not found in CTS (where the primary is hex encoded) and the logon continues.

Like I wrote in the description I locally changed the SAML2CTSPersistentStore.retrieveSAML2Token method to encode the primary key before attempting to read the assertion. That currently works.

I hope this helps. If you have anymore questions don't hesitate to ask me.

Comment by Peter Major [X] (Inactive) [ 02/Feb/15 ]

The SAML primary IDs and secondary IDs are now consistently encoded when interacting with CTS, and are decoded when the SAML codebase needs to use the tokens.

Resolved with R12288 R12293 and R12294

Generated at Sat Oct 24 00:54:30 UTC 2020 using Jira 7.13.12#713012-sha1:6e07c38070d5191bbf7353952ed38f111754533a.