[OPENAM-12171] PolicySetCache gets corrupted when the realm name contains upper case characters Created: 03/Dec/17  Updated: 29/Jul/19  Resolved: 09/Dec/17

Status: Closed
Project: OpenAM
Component/s: policy
Affects Version/s: 6.0.0
Fix Version/s: 6.0.0, 14.1.2, 5.5.2

Type: Bug Priority: Major
Reporter: Peter Major [X] (Inactive) Assignee: Peter Major [X] (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates
relates to OPENAM-14685 PolicySetCacheImpl is not cleaned up ... Resolved
Target Version/s:
Needs backport:
Yes
Verified Version/s:
Needs QA verification:
Yes
Functional tests:
No
Are the reproduction steps defined?:
Yes and I used the same an in the description

 Description   

Bug description

PolicySetCache does not correctly clean up the cache upon realm deletion, meaning that old policy sets can stick around in the cache.

How to reproduce the issue

  • create realm foo
  • create a policy set in realm foo
  • delete realm foo
  • create realm foo
  • at this point REST calls to retrieve the policyset will still work even though the policy set does not actually exist any more.
Expected behaviour

The cache is cleared when a realm is deleted.

Current behaviour

It isn't.



 Comments   
Comment by Ľubomír Mlích [ 29/Jul/19 ]

Reproduced in ForgeRock Access Management 5.5.1 Build 96b47ad4f1 (2017-October-26 15:41), in attempt to evaluate policy for user I see access denied:

[
    {
        "actions": {},
        "advices": {},
        "attributes": {},
        "resource": "http://openam.example.com:38080/helloworld/index.html",
        "ttl": 9223372036854775807
    }
]

Verified as fixed in ForgeRock Access Management 5.5.2-M6 Build 871fe7a608 (2019-July-23 10:08), I see configuration does not exists:

{
    "code": 404,
    "message": "Unable to retrieve application under realm /Test.",
    "reason": "Not Found"
}
Comment by Ľubomír Mlích [ 29/Jul/19 ]

no more verification

Generated at Wed Nov 25 05:20:24 UTC 2020 using Jira 7.13.12#713012-sha1:6e07c38070d5191bbf7353952ed38f111754533a.