13.5.0, 13.5.1, 14.1.1, 5.5.1, 6.0.0, 18.104.22.168, 22.214.171.124, 126.96.36.199, 188.8.131.52, 184.108.40.206, 6.5.0, 220.127.116.11, 18.104.22.168
Same behaviour in 13.5.1 and 22.214.171.124
When performing SAML2 authentication (AM as the IDP with SAML2 Failover enable) and if the same SAML2 SP authentication is done (where AM IDP SAML2 is still logged in and is still intact), the following exception will be logged in CoteSystem log
We are interested only on the AM IDP but since this involves a testing client, we need to install an SAML2 SP too. However focus on the IDP logs
- Install AM IDP (AM-1)
- Install AM SP (AM-2)
- You can configure a SAML2 Integrated module on AM-2 (SP) to authenticate to IDP
- Ensure in Global > SAML2 Configuration on AM IDP > SAML2 Failover is enabled
- Test the flow that doing an authentication on AM-2 using the SAML2 auth module works
- Now clear the session cookie on the SP2 side.
- Now repeat the access the AM-2 to trigger the SAML2 auth (but there is a IDP session)
- Observe that the repeated SAML2 authentication will cause the above exception
This is not really much of an issue when this exception happens.
There is no problem other than logs registering that there is an entry existed.
For now you can ignore this exception.
The saving code always uses CTS create to create the entry and fails if it
already exists. Note that another for this may be in Saml2SessionUpgradeHandler that one may want to check too.
PS: The only hard part of this issue is that say in AM65 with error level logging, the above exception is seen but it is hard to tell the cause leading to it if loglevel is not increased. (For this issue, since we are replicating it we know the cause for this SAML2 entry as we can also check the CTS entries)
- Maybe the saveSAML2Token should be a upsert (available on 6.5.x)
- It is also possible that at least for this error it can be ignored too.