[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
|Fix Version/s:||11.0.3, 12.0.1, 13.0.0|
|Reporter:||Joost Zalmstra [X] (Inactive)||Assignee:||Peter Major [X] (Inactive)|
|Remaining Estimate:||Not Specified|
|Original Estimate:||Not Specified|
|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:
|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.
|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