We continue to have trouble with the caching of attribute repository values.
Our issue is similar to
https://groups.google.com/a/apereo.org/g/cas-user/c/0HjUqWsM0oE, but defining attribute repositories ids doesn´t fix all of it.
Scenario:
CAS 7.2.4. New requirement is the deactivation of caching for attribute repositories in OIDC authentication requests.
To enable this, We've changed the following policy in the service definitions of all registered OIDC services:
"attributeReleasePolicy": {
"@class": "org.apereo.cas.services.ReturnAllAttributeReleasePolicy",
"mergingPolicy": "REPLACE",
"principalAttributesRepository" : {
"@class" : "org.apereo.cas.authentication.principal.cache.CachingPrincipalAttributesRepository",
"expiration" : 1,
"timeUnit": "SECONDS",
"mergingStrategy" : "REPLACE",
"attributeRepositoryIds": ["java.util.HashSet", ["attribute-repo-1", "attribute-repo-2", "attribute-repo-3", "attribute-repo-4"]],
"ignoreResolvedAttributes": true
}
}
What happens:
When using code authorization with an existing SSO session cookie and a second client, the JWT returned by /oidcAccessToken includes attributes from the original sign-in merged with the newly loaded attributes. I use /oidcAuthorize and /oidcAccessToken.
When using code authorization with an existing SSO session cookie and the original client, the JWT returned by /oidcAccessToken includes only the original attributes.
We tried to debug CAS to figure out the source. In /oidcAccessToken the ChainingPrincipalAttributesRepository is used.
However, during the /oidcAuthorize request, the DefaultCentralAuthenticationService is called. In line 137, the merger is hardcoded as MULTIVALUED. We think this is where the merging starts to happen and the principal is updated. As this function is not called in the same-client scenario, we think the old princilpe values are returned.
What we expect:
With every /oidcAccessToken request, the JWT should only include the newly fetched attributes, replacing the old attributes.
Regards,
Benedikt