SiteMinder Policy Server stores the JSON objects in the session store as string rather than a JSON object format.
Article ID: 371973
Updated On:
Products
Issue/Introduction
Please note that this behavior did not exist prior to release 12.8.SP8.
- Use Case flow (Just for reference only):
1) Application make a GET with JWT token as Bearer token call to https://accessgateway.XXXX.com/affwebservices/protected/jwt_auth_scheme.html
2) SiteMinder authentication using JWT Authentication scheme and authenticates the JWT token.
3) After successful JWT token authentication, SiteMinder then parses the JWT token claims and then stores all of the claim values in the session store and generates a SMSESSION cookie.
4) The web browser obtain the SMSESSION cookie and then invoke an IDP-initiated SSO request:
https://accessgateway.XXXX.com/affwebservices/public/saml2sso?SPID=SPPartnerXXXX
5) SPPartnerXXXX federation partnership configuration retrieves the SAML attribute values from the session store using the SMSESSION cookie.
6) Federation partnership then generates SAML assertion with SAML attribute data obtained from the session store.
------ Below is the value of the JSON object as it is stored in the session store with the release 12.8.06a policy server version as it extracted this data from the JWT claims:
[{"dob":"XX\/XX\/XXXX","name":"Username1 TESTXXXX100","id":"CVGID-3700XXXX-24003XXXX-02"}]
------ Below is the value that observed in the session store with the r12.8 SP8 CR1 policy server:
[{id=CVGID-3700XXXX-24003XXXX-02, name=Username1 TESTXXXX100, dob=XX/XX/XXXX}]
As mentioned above, with the release 12.8 SP8 CR1, the JSON object is no longer stored in the session store with its correct JSON format and causes functionality issues.
Environment
Release : 12.8.08 CR1 (12.8 SP8 CR1) (Applicable to release 12.8 SP8 and above)
Component: SMPLC
Cause
Kindly note that this is a known issue due to third party defects and we have listed in the SiteMinder documentation as well.
------ Document reference:
https://techdocs.broadcom.com/us/en/symantec-security-software/identity-security/siteminder/12-8/release-notes/known-issues/known-issues-for-policy-server.html#concept.dita_c30a346faa0cc09c960740a3e1dc4b6289a43f27_ResponseVariableFormatDifference
- Snippet from documentation:
- Symptom:
The response variable that is generated for a JWT authentication scheme is different. The keys and string values are not enclosed in quotes.
------ Response variable format in releases prior to 12.8.08:
{"levelone":{"leveltwo":{"levelthree":{"emailAddress":"user3","levelfour":{"levelfive":{"levelsix":{"emailAddress":"user3","levelseven":{"leveleight":{"levelnine":{"emailAddress":"user3","levelten":{"emailAddress":"user3","salary":600000.0,"age":27},"salary":600000.0,"age":27}}},"salary":600000.0,"age":27}}},"salary":600000.0,"age":27}}}}
------ Response variable format from Release 12.8.08:
"{levelone={leveltwo={levelthree={emailAddress=user3, levelfour={levelfive={levelsix={emailAddress=user3, levelseven={leveleight={levelnine={emailAddress=user3, levelten={emailAddress=user3, salary=600000.0, age=27}, salary=600000.0, age=27}}}, salary=600000.0, age=27}}}, salary=600000.0, age=27}}}}"
Resolution
The changed behavior is expected due to a change in the " Nimbus-JOSE-JWT " third-party behavior and that this can not be changed due to the underlying JSON lib being replaced.
This behavior is observed in a JWT authentication scheme in the following scenario.
The Persist Authentication Session Variable field is selected in the authentication scheme configuration.
In the domain that is protecting the resource with the JWT authentication scheme, a response is configured to use a complex claim that is persisted from an incoming JWT during authentication.
Since this is a third-party issue and they wouldn't be addressing the problem, unfortunately there is not much we can do at this point.
This has been already documented as mentioned above.
But our Internal team developed a workaround solution and the workaround solution is working as expected.
------ Workaround Solution:
According to our test, JWT Authentication scheme in 12.8 SP8 CR1 does not handle JSON objects with arrays.
We have modified the array into a string with a JSON object.
Before Changing
"mids":[
{
"id": "CVGID-3700XXXX-24003XXXX-02",
"name": "Username1 TESTXXXX100",
"abc": "xx/xx/xxxx"
},
{
"id": "CVGID-3700XXXX-24003XXXX-03",
"name": "Username2 TESTXXXX100",
"ghi": "xx/xx/xxxx"
},
{
"id": "CVGID-3700XXXX-24003XXXX-00",
"name": "Username TESTXXXX100",
"def": "xx/xx/xxxx"
}
]
After changing
"mids": "[{\"id\": \"CVGID-3700XXXX-24003XXXX-02\",\"name\": \"Username1 TESTXXXX100\",\"abc\": \"xx/xx/xxxx\"},{\"id\": \"CVGID-3700XXXX-24003XXXX-03\",\"name\": \"Username2 TESTXXXX100\",\"ghi\": \"xx/xx/xxxx\"},{\"id\": \"CVGID-3700XXXX-24003XXXX-00\",\"name\": \"Username TESTXXXX100\",\"def\": \"xx/xx/xxxx\"}]"
Then, it works fine.
Again, please note that the changed behavior is expected due to a change in the third-party behavior so we don't have any solution at this stage so kindly use the provided WORKAROUND Solution to move further If you observe this issue.
Feedback
