Hello, After upgrading from OAS 7.6 to OAS 8.2, our custom SQL Group Provider stopped working correctly in Enterprise Manager. In Application Roles → Members → Add, searching for a custom database group always returns: Group not found The groups exist in our custom tables and authorization continues to work for existing roles. Only searching/adding groups from EM is affected. We verified that: * The provider configuration is unchanged (bisql-group-providerType). * JDBC datasource is working. * No errors appear in AdminServer, bi.log or bi_server1.log. * V$SQL shows only the following query being executed: SELECT G_NAMEFROM OASPROD_BIPLATFORM.EPIAS_OBI_GROUP_MEMBERSWHERE UPPER(G_MEMBER)=UPPER(:1) The configured sql-list-groups and sql-group-exists queries are never executed. The exact same configuration works correctly on our OAS 7.6 environment. Has anyone experienced this after upgrading to OAS 8.2? Is this a known issue or behavior change with bisql-group-providerType? Thanks in advance.

nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Oracle Communities

Oracle Analytics and AI

Child Item

OAS 8.2 - Custom SQL Group Provider cannot find database groups in Enterprise Manager

dilek

Hello,

After upgrading from OAS 7.6 to OAS 8.2, our custom SQL Group Provider stopped working correctly in Enterprise Manager.

In Application Roles → Members → Add, searching for a custom database group always returns:

Group not found

The groups exist in our custom tables and authorization continues to work for existing roles. Only searching/adding groups from EM is affected.

We verified that:

The provider configuration is unchanged (bisql-group-providerType).
JDBC datasource is working.
No errors appear in AdminServer, bi.log or bi_server1.log.
V$SQL shows only the following query being executed:

SELECT G_NAMEFROM OASPROD_BIPLATFORM.EPIAS_OBI_GROUP_MEMBERSWHERE UPPER(G_MEMBER)=UPPER(:1)

The configured sql-list-groups and sql-group-exists queries are never executed.

The exact same configuration works correctly on our OAS 7.6 environment.

Has anyone experienced this after upgrading to OAS 8.2? Is this a known issue or behavior change with bisql-group-providerType?

Thanks in advance.

Find more posts tagged with

OAS 2025

Accepted answers

Gianni Ceresa

I did use grantAppRole , which let you add an application role, a group or a user to an application role.

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

The parameter that let me bypass any check of the existance of the groups is the "forceValidate" that is true by default.

The "principalClass" of your groups is always "weblogic.security.principal.WLSGroupImpl", doesn't matter where the groups come from (native WebLogic groups or from the SQL provider).

All comments

dilek

Any comment please :)

Brendan T

Have you opened an SR for this? If not, consider opening one.

Gianni Ceresa

As the security still works, is that really an issue?

You can't handle it from EM, but you can still do it via WLST, because it has a parameter to not check the existence of a group, therefore will add your groups to the role you need, without complaining. And once a group added to a role it will just work like all your existing groups.

I did that some time ago when using the SQL provider in the security, but can't remember what version it was exactly.

I anyway always use WLST scripts to handle the security model, because it let me version them and also keep track of changes and evolutions easily.

dilek

Thanks for your reply @Gianni Ceresa ,

Yes, runtime authorization still works correctly. The only issue is that Enterprise Manager cannot find SQL provider groups anymore after upgrading to OAS 8.2. So, if I need a new application role, then I can not add it to system.

Could you please share which WLST command you used? Was it addMembersToApplicationRole() with the parameter to skip group existence validation?

That would be very helpful.

Gianni Ceresa

I did use grantAppRole , which let you add an application role, a group or a user to an application role.

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

The parameter that let me bypass any check of the existance of the groups is the "forceValidate" that is true by default.

The "principalClass" of your groups is always "weblogic.security.principal.WLSGroupImpl", doesn't matter where the groups come from (native WebLogic groups or from the SQL provider).

dilek

Thank you, it worked.

I created the Application Role from Enterprise Manager and then used:

grantAppRole(    appStripe='obi',    appRoleName='my_new_app_role',    principalClass='weblogic.security.principal.WLSGroupImpl',    principalName='my_db_group_name',    forceValidate='false')

The SQL Group Provider group was successfully added to the Application Role.

This confirms that the issue is only with Enterprise Manager's group validation after the upgrade. The SQL Group Provider itself is working correctly.

Gianni Ceresa

As I always handle security via WLST scripts, I can't say if I faced the issue in the EM web interface in previous upgraded environments.

But it is an extra argument in favour of having your whole security model handled by script with all the benefits it brings.