Policy decision resolve to 403 despite user being allowed to access specified resource

[glchua2]

Describe the bug Policy decision resolve to 403 forbidden despite usergroup (that current user belong to) are configured to allow access to affected URL.

Prerequisite

• Configure OpenIG to be Policy Enforcement Point and OpenAM as Policy Decision Point.
• OpenIG contain existing routes to route to sample application through https://sample.app.io:443/

To Reproduce Steps to reproduce the behavior:

1. Create relevant usergroup (operator) and user(user1):
2. Create relevant policy using rest API since there are currently issue with editing Subjects via UI with the following: Subjects "subject": { "type": "AND", "subjects": [ { "type": "OR", "subjects": [ { "type": "Identity", "subjectValues": [ "id=operator,ou=group,o=myrealm,ou=services,dc=openam,dc=forgerock,dc=org" ] } ] }, { "type": "AuthenticatedUsers" } ] } Resources "resources": [ "https://sample.app.io:443/AlarmList.html", "https://sample.app.io:443/AlarmList.html?*" ] Actions "actionValues": { "GET": true }
3. Login as user1.
4. Try to access https://sample.app.io:443/AlarmList.html in browser and user will be greeted with Forbidden page.

Expected behavior User should be able to access https://sample.app.io:443/AlarmList.html since subject conditions should evaluate to true.

Desktop (please complete the following information):

• OS: Windows 10
• Browser Chrome(88.0.4324.150), Firefox (85.0.2)

Additional context

• If Subjects are updated to "subject": { "type": "AuthenticatedUsers" } user1 are now able to access https://sample.app.io:443/AlarmList.html without encountering Forbidden page

[sp193]

We are still experiencing this issue with OpenAM 14.7.3. Through more trial-and-error, I noted that this authorization problem is not present if I either:

1. Allow all authenticated users.
2. Allow a specific user by user ID, rather than group ID.

Within the logs of OpenAM, it appears that the user's membership is not being evaluated properly:

amPolicy:09/22/2023 03:08:19:872 PM SGT: Thread[http-nio-9090-exec-3,5,main]: TransactionId[271a46e7-3501-44c6-9e6d-86bafaa95f04-114]
AMIndentitySubject.isMember(): entering with userDN = id=admin,ou=user,o=iot_platform,o=wisx,ou=services,dc=openam,dc=forgerock,dc=org
amPolicy:09/22/2023 03:08:19:873 PM SGT: Thread[http-nio-9090-exec-3,5,main]: TransactionId[271a46e7-3501-44c6-9e6d-86bafaa95f04-114]
AMIndentitySubject.isMember(): checking membership with userDN = id=admin,ou=user,o=iot_platform,o=wisx,ou=services,dc=openam,dc=forgerock,dc=org, subjectValue = id=admingroup,ou=group,o=IOT_Platform,o=WISX,ou=services,dc=openam,dc=forgerock,dc=org
amPolicy:09/22/2023 03:08:19:873 PM SGT: Thread[http-nio-9090-exec-3,5,main]: TransactionId[271a46e7-3501-44c6-9e6d-86bafaa95f04-114]
IdentitySubject:isMember():entry for id=admingroup,ou=group,o=IOT_Platform,o=WISX,ou=services,dc=openam,dc=forgerock,dc=org not in subject evaluation cache, so compute using IDRepo api
amPolicy:09/22/2023 03:08:19:873 PM SGT: Thread[http-nio-9090-exec-3,5,main]: TransactionId[271a46e7-3501-44c6-9e6d-86bafaa95f04-114]
IdentitySubject.isMember():user uuid = id=admin,ou=user,o=iot_platform,o=wisx,ou=services,dc=openam,dc=forgerock,dc=org, subject uuid = id=admingroup,ou=group,o=IOT_Platform,o=WISX,ou=services,dc=openam,dc=forgerock,dc=org
amPolicy:09/22/2023 03:08:19:873 PM SGT: Thread[http-nio-9090-exec-3,5,main]: TransactionId[271a46e7-3501-44c6-9e6d-86bafaa95f04-114]
IdentitySubject.isMember():userIdentity type IdType: user can be a member of subjectIdentityType IdType: group:membership=false

OpenAM's UI recognizes that the "admin" user is a member of "admingroup".

This is what @glchua2 tried:

This is what works for me (not ideal for our usecases):

Does anyone have any hints for me, as to what might be wrong? I find it difficult to believe that something this essential, does not work in the open-source version of AM, so surely I must have overlooked something. My config & user data store is opendj 4.5.6.

[sp193]

I attached a remote debugger to it, to step through the code that evaluates the membership of the user & the user group.

From the point where the evaluation is made:

                        subjectMatch = userIdentity.isMember(subjectIdentity);

... which calls AMIdentity.isMember(), where there is:

        if (identity!=null && !getRealm().equals(identity.getRealm()))
            return false;

At this point, if I print the two values:

http-nio-9090-exec-8[1] eval getRealm()
 getRealm() = "o=iot_platform,o=wisx,ou=services,dc=openam,dc=forgerock,dc=org"
http-nio-9090-exec-8[1] eval identity.getRealm()
 identity.getRealm() = "o=IOT_Platform,o=WISX,ou=services,dc=openam,dc=forgerock,dc=org"

It would appear that the session user's realm has been transformed to lowercase, but the comparison is case-sensitive. I think it may be an unusual choice for comparing X.500 principals, but I do not know enough about AM's design to know if it is actually permissible. The relevant change might have been 500040f, which was made back in 2019.

If I started with 14.4.2 before attempting to upgrade to 14.5.1, this issue will appear after the upgrade. 14.4.2 was the last version before this commit was included in any releases.

[sp193]

The fix appears to have solved the problem. So once it is made into a release, we can close this issue. Thanks @vharseko .