API to perform batch assignments between users and application roles that can automate the process

Shinya

Organization Name (Required - If you are an Oracle Partner, please provide the organization you are logging the idea on behalf of):

Shiseido Co., Ltd.

Enhancement Request / Service Request:

[Requirement]

We would like an API to perform batch assignments between users and application roles, groups and application roles,

which can currently only be done through the Web UI (Console). 

We would like to have an API that can automate the process of assigning roles and permissions to new or existing users.

Description (Required):

[Summary]

The existing system (BIEE), which currently has 35,000 registered users and is used by approximately 5,000 users per month, will be migrated to OAC.

Go-live and switchover is March 2023. We are considering reducing the number of registrants, but expect a maximum of 35,000.

*Problems

 The existing system (BIEE) uses an initialization block for authentication.

 User and group registration and role assignment are performed in batch execution.

 User information is maintained in a dedicated system (common ID infrastructure) that manages user information and is linked once a day by batch execution.

 Batch execution assigns the organization's roles and roles that summarize job classifications to user information on the BIEE side,

 and also sets authorization information.

 It is difficult to perform the same process manually on the Web UI (Console) in OAC, and it cannot be completed within the batch window time.

*Why is it difficult to use the API for IDCS groups and why do we need the API for application roles?

 (1) The existing system (BIEE) control has created roles for the organization and there are 150 roles.

 (2) Shiseido's common Azure ID platform (Azure AD) that distributes user information to Oracle IAM, does not allow user information to include group information for individual systems.

   For this reason, individual systems, including OAC, prepare application roles and use them in conjunction with user information.

   Therefore, it should be managed by application roles.

[Table of Contents]

1. Management Policy of User Information of Shiseido Employees

2. Policy for Achieving Certification Authorization in OAC

3. Business Needs

[Details]

1. Management Policy of User Information of Shiseido Employees

  The management of employee user information

  is centrally managed in a separate dedicated system (common ID infrastructure), including revision and abolition of user information,

  separately from each business system existing within Shiseido, including OAC, which is to be introduced this time.

  There are several business systems in Shiseido, including OAC, which will be introduced this time.

  Each business system is configured to authenticate according to the design policy of each business system 

  using user information linked from the common ID infrastructure.

  Authorization information is basically not managed in the common ID infrastructure.

  Therefore, when each business application controls authorization, 

  in addition to authentication information of IDs and passwords,

  user information such as affiliation and job classification, which is necessary for authorization control,

  is obtained from the common ID infrastructure through IF linkage,

  and then the authorization information is revised, abolished, and managed on the business system side.

  The common ID infrastructure

  usually performs a nightly batch process once a day,

  and all user information, including that of the day's revision or abolition, is linked to other business systems by IF by the next morning.

2. Policy for Achieving Certification Authorization in OAC

  We are currently using BIEE 11g and plan to migrate the system, including operations, to OAC as is.

  For reference, BIEE 11g uses DB data to control authentication and authorization.

  In implementing OAC, SSO certification is an individual requirement.

  Therefore, we will follow the aforementioned management policy for authentication authorization information

  but we plan to achieve authentication by linking authentication information from the common ID infrastructure to Oracle IAM via Azure AD.

  Although group information is also linked from Azure AD to Oracle IAM, as described in "1. Management Policy of User Information of Shiseido Employees,"

  group information cannot be changed due to individual requirements on the OAC side because other business systems are also used.

  For authorization information,

  based on the user information linked directly from the system that manages user information through IF linkage,

  multiple processes (similar to those in the current BIEE 11g) are performed according to requirements,

  and authorization information is once created as DB data separately from the OAC.

  On top of that, authorization control itself needs to be implemented as a role of the OAC application.

  Therefore, the policy is to realize authorization by linking OAC application roles and users on OAC via REST API, etc.

  based on authorization information in DB data before user use begins.

  Due to business requirements, we are currently operating about 150 BIEE application roles, 

  and plans to continue operating the same number of OAC application roles after OAC is deployed.

Use Case and Business Need (Required):

3. Business Needs

■Overview of Use Case for Updating Authorization Information

 In the current operation in BIEE 11g before the introduction of OAC,

 BIEE application roles are generally created and operated for each department to which the user belongs,

 since the range of data that can be referenced differs depending on the user's role and department.

 Currently, a total of approximately 150 application roles are in operation,

 and the same application roles will need to continue to be operated after OAC is introduced.

 Therefore, it is necessary to update the information linking OAC application roles every time a user's role changes or a personnel change occurs.

 Note that the current BIEE 11g automates the above process.

 If this must be done manually in the OAC, there is concern about increased work costs

 and lost opportunities due to unavailability until the work is completed, which could impact operations.

■Details for Each Use Case when Updating Authorization Information

Use Case #1: Personnel Transfer Without Organizational Change

 This occurs when new graduates/mid-career employees join or leave the company or change departments.

 Several dozen orders are generated each month, and several hundred orders may be generated at semi-annual milestones (around January and July).

 There is no specific date when this will be changed, 

 and the range obtained from the daily IF linkage should be updated each time a change occurs.

 Since the consolidation of departments does not usually occur, the addition of OAC application roles corresponding to departments almost never occurs, and only the users associated with them are changed.

Use Case #2: Personnel Change with Organizational Change

 It occurs once or twice a year, mainly semiannually, due to organizational or departmental changes or consolidation in accordance with management policies.

 Not every time, but sometimes thousands of orders are generated.

 Since the system is to be used in its unchanged state until the day before the predetermined switchover date,

 all settings must be completed between the end of business hours on the previous day and the beginning of business hours the next morning.

 Usually, new application roles are added when departments change, and personnel changes also change users by the order of thousands.

■Issues That Arise when Updating Authorization Information

 When updating authorization information in each of use case #1 and #2 above,

 The situation of linking OAC application roles to Oracle IAM users and groups

 can only be done manually through the OAC GUI, which is practically impossible in terms of both timing and volume.

 In this regard, Oracle introduced the following page.

  https://community.oracle.com/customerconnect/discussion/548210/api-for-assigning-roles-and-permissions-to-a-new-user-in-oracle-analytics-server-oa

 The following measures can be taken to deal with use case #1.

 Create approximately 150 Oracle IAM groups corresponding to OAC application roles

 using names that do not duplicate group information linked from Azure AD,

 and link OAC application roles to Oracle IAM groups.

 Connect approximately 35,000 Oracle IAM users to approximately 150 Oracle IAM groups using the REST API.

 However, 

 in addition to modifying or abolishing (renaming, adding/deleting, etc.) about 150 OAC application roles,

 in the case of OAC, it is necessary to manually link about 150 additional OAC application roles to Oracle IAM groups one by one, rather than in a batch.

 The following issues remain when OAC is introduced and in use case #2.

 Issue #1: Need to manually tie approximately 150 OAC application roles to Oracle IAM Groups the first time OAC is set up.

 Issue #2: When adding, modifying, or eliminating OAC application roles corresponding to a department in use case #2, it is necessary to manually add or update the Oracle IAM group ties.

 Issue #3: If the group on the Azure AD side corresponding to the department in use case 2 is modified or abolished, the group on the Oracle IAM side must also be modified or abolished,

      and then the process of manually linking it to the approximately 150 application roles in the OAC must be re-performed.

 Regarding issue #1, the switchover to OAC is scheduled for the end of March 2023 as a milestone, and immediate action is needed by then.

 In addition, especially with regard to issue #2 and #3, 

 Tight time constraints after data is IF linkage, considering the impact on other business systems.

 It is expected that a large number of settings, including the update of authorization information described in "2. Policy for Achieving Certification Authorization in OAC,"

 will continue to be completed through the night, so immediate action is also needed.