Oracle Communities

Oracle Analytics and AI

Child Item

Issues when manually adding Groups to Roles in Enterprise Manager

Hello,

Since upgrading to OAS 2025, we've noticed a new behavior… when creating or editing a new Application Role in EM, we typically click the "Advanced Option" and manually enter the Principle Name that is stored in our BISQLProvider custom configuration, then click OK. Normally it would just add that value to the group, but now it appears there is some kind of validation on this step that didn't happen before?

We can add users here with no issue. Has anyone else noticed this behavior?

Regards,

Chad Williams

Find more posts tagged with

Weblogic

OAS2025

Accepted answers

Gianni Ceresa

For a quick test, when running %ORACLE_HOME%\oracle_common\common\bin\wlst.sh you are in an interactive session inside WLST.

You can enter these commands:

connect('<admin username, like weblogic>', '<password>', 't3://localhost:9500')
grantAppRole(principalClass='weblogic.security.principal.WLSGroupImpl', principalName='<group name>', appStripe='obi', appRoleName='<approle name>', forceValidate='false')
exit()

You need to be "online" to modify the security.

If your OAS has SSL enabled, you should replace the server address by 't3s://<domain name>:9501' (or the correct port number if not the default one).

A Weblogic training? Good luck: that product is huge, every time I believe it's just a single checkbox, I discover there is a whole book explaining how something work :D

All comments

RajeshPolavarapu-Oracle

Looks like there is an additional validation introduced for manual entry as well.

Is that particular group searchable - RCA_RSP_AUTHOR in normal option (not the advanced one) when you search for it .

Steve F-2

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

Gianni Ceresa

Hi Chad,

If I'm not wrong, when I last used the BISQLGroupProvider, I had a similar issue. But I was working with WLST, and I found one of the commands had a flag to ignore the check and just add the group name I entered without verifying anything.

I need to go through my notes to see if I find the details of what I was doing and how I handled it (it was definitely in the security setup that I had the issue and found that flag, but I prefer to verify if it is exactly in the same context you are facing, and if the flag is still there).

I will post back the details if it is the case :)

Gianni Ceresa

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

@SteveF-Oracle From what I can see, in the console, if I go to an Application Role, and try to add a group, I see only a handful of groups, from the OAS System, and possibly from Active Directory, I'm presuming. The groups defined in our BISQLProvider don't show up there and you can't do any kind of a manual override. I'm going to bring an old system backup and see what the console behavior is there in OAS 2022.

Chad Williams

@Gianni Ceresa I guess the big question I'm seeing here… Do I have run that for every single role we have, or is there a global setting to set the force validation to be false rather than true?

Chad Williams

@SteveF-Oracle Am not able to add groups to roles in OAS2022 Console either, but am able to do so in EM

Gianni Ceresa

@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.

Chad Williams

https://community.oracle.com/products/oracleanalytics/discussion/comment/67852#Comment_67852

Thanks yes, going to get the WLST going, try the command, and see what happens. I haven't had to spend very much time if any in the WLST so this be a slight lift for me. Need to finish that Weblogic training ;)

Gianni Ceresa

For a quick test, when running %ORACLE_HOME%\oracle_common\common\bin\wlst.sh you are in an interactive session inside WLST.

You can enter these commands:

connect('<admin username, like weblogic>', '<password>', 't3://localhost:9500')
grantAppRole(principalClass='weblogic.security.principal.WLSGroupImpl', principalName='<group name>', appStripe='obi', appRoleName='<approle name>', forceValidate='false')
exit()

You need to be "online" to modify the security.

If your OAS has SSL enabled, you should replace the server address by 't3s://<domain name>:9501' (or the correct port number if not the default one).

A Weblogic training? Good luck: that product is huge, every time I believe it's just a single checkbox, I discover there is a whole book explaining how something work :D