Unfortunately, we were not able to narrow the environment condition to explain how to reproduce it. However, debug logs demonstrate that this is actually happening.
For QA testing this issue, just make sure that the DAS can deserialize the
Any module calling "getHttpServletRequest()" would do the job. Adaptive risk, Cert, etc.
In some rare condition, the deserialization of the HttpServletRequest, more precisely the attribute:
can end in a corrupted state, which prevents reading headers.
This map is supposed to store: CaseInsentitveKey -> Object but offers an API which allows accessing the Object via their sensitive value.
The problem from this design, which can allows a String key to be stored instead of its equivalent CaseInsentitiveKey.
As CaseInsentitiveKey overrides the hashcode function:
The String key would be stored in a different place in the map.
ie : "myHeader" would be stored in
, whereas "new CaseInsentitiveKey("myHeader")" would be stored in
For reference, that's how objects are stored in a HashMap.
In the case of the RemoteHttpServletRequest, the headers can be ended stored as a String, causing the deserialization to fail on the OpenAM server side. ie: OpenAM tries to find a header "myHeader" on position 21 but can't find it.
The fact that the RemoteHttpServletRequest uses this CaseInsensitiveHashMap is not necessary. It's probably imported for an old OpenAM that needed to be Java 5 compliant. We could simplify this function by refactoring the internalHeaders attribute into:
That way, Java itself will make sure we couldn't end with a String key on this map.