ENDORSE any-user to {GROUP_MEMBERSHIP_INSPECT, AUTHENTICATION_INSPECT} in tenancy user_tenancy
While using any-user makes it easy to understand the required policies, Oracle recommends that you use stronger constraints in addition to or instead of using any-user. The any-user option will allow any principal or resource to query user groups in the user_tenancy. Ideally, you should limit this to just allowing the database resources (resource principals) to make the group queries. You can do this by adding a WHERE clause to the policies or by adding a dynamic group that limits it to the members of the dynamic group. Defining every possible way to specify dynamic groups and policies is outside the scope of this topic. You can find more information from these sources:
CREATE USER schema1 IDENTIFIED GLOBALLY
AS 'IAM_PRINCIPAL_NAME=ocid1.tenancy.OCID:example_domain/peter.fitch@oracle.com';
CREATE USER schema2 IDENTIFIED GLOBALLY
AS 'IAM_PRINCIPAL_NAME=ocid1.tenancy.OCID:peter.fitch@oracle.com';
CREATE USER qa_db_user_group IDENTIFIED GLOBALLY
AS 'IAM_GROUP_NAME=ocid1.tenancy.OCID:example_domain/xt_db_users';
CREATE USER qa_sales_user_group IDENTIFIED GLOBALLY
AS 'IAM_GROUP_NAME=ocid1.tenancy.OCID:sales_users';
CREATE USER xt_ip_user IDENTIFIED GLOBALLY
AS 'IAM_PRINCIPAL_OCID=ocid1.instance.region1.sea.OCID';
GRANT CREATE SESSION TO xt_ip_user;
CREATE USER xt_iam_dg IDENTIFIED GLOBALLY
AS 'IAM_GROUP_NAME=ocid1.tenancy.region1.OCID:sales_principals';
GRANT CREATE SESSION TO xt_iam_dg;
CREATE ROLE globalrole1 IDENTIFIED GLOBALLY
AS 'IAM_GROUP_NAME=ocid1.tenancy.abcdef:example_domain/xt_db_users';
CREATE ROLE globalrole2 IDENTIFIED GLOBALLY
AS 'IAM_GROUP_NAME=ocid1.tenancy.abcdef:sales_users';