Additionally, does similar behavior occur in OA Console > Application and Roles?

Found my notes…

So, I was adding groups from the SQL provider as members of application roles using WLST, and it was complaining that it couldn't find the groups.

While digging at what the grantAppRole function was doing, I found the definition of the function itself:

def grantAppRole(appStripe=None, appRoleName=None, principalClass=None, principalName=None, identityDomain=None, idcsAppName=None, forceValidate="true")

As you can see there is a parameter forceValidate="true"which is enforced as true by default when not provided in WLST.

The official doc of the FMW 12.2.1.4 OPSS WLST commands only list a subsets of those parameters: https://docs.oracle.com/en/middleware/fusion-middleware/platform-security/12.2.1.4/idmcr/security_wlst.html#GUID-80708E0B-71D2-4471-ABA8-018147F3FE34

And obviously that forceValidate wasn't listed.

But by using it with forceValidate="false", I did add all my groups to the various application roles and the security works perfectly.

My guess is that the EM GUI is now also enforcing this default "true" value for the validation somehow, so you could try by using WLST and setting that parameter to false.

This is what I was using:

grantAppRole(principalClass='weblogic.security.principal.WLSGroupImpl', principalName='<group name>', appStripe='obi', appRoleName='<approle name>', forceValidate='false')

I'm fairly sure the principal class of your groups is weblogic.security.principal.WLSGroupImpl, because it's the same for the past 15 years (if you have a working environment with a SQL group mapped to an approle, you can use listAppRoleMembers to get the members, and next the name of each member the command will show you the principalClass value as well).

As a general topic, I usually avoid configuring the security (users, groups, app roles and members, policies etc.) manually in EM, because it's very easy to miss a setting or have a spelling issue etc. I always configure the security as WLST scripts (it's python 2, a bit limited but allows to do everything you can do in Console and EM, and most of the time it's just a long list of commands with the various names of the groups and app roles hardcoded). The benefit of a script is that I can version it and keep track of the changes over time, and in 1 execution I can recreate a whole security model exactly as needed again and again by just running: %ORACLE_HOME%\oracle_common\common\bin\wlst.sh my_security_setup_script.py

@Chad Williams ,

That command, the grantAppRole , is to add a single group as member of an application role. So, yes: the forceValidate='false' is in each and every call to that command.

My WLST scripts to setup the security model easily have 50-100 commands for not too complex security models: it starts by creating all the application roles I need, followed by adding all the members I need and continue by granting special policies if needed.

It often starts with an Excel file with a pivot of users/groups/roles and roles, and that generate me all the commands to create all the application roles and all the associations between users/groups/roles and roles. Just because seeing that pivot in Excel make it easier to have a global vision of the security model and make sure I don't have "holes" (too many grants, or not enough).

From there it becomes a script and then if it's only small changes, I modify the script directly and use git to keep track of the changes (and why I did them).

I don't have any clue if the issue you are facing can be "fixed" by using that parameter in that command, it did work for me when the system was complaining my group didn't exist and it did refuse to add it as member of an application role. Maybe something worth a test, because it could also help Oracle in telling how to change that behaviour in the GUI.