DISTRIBUTED MULTI-STAGE AUTHORIZATION APPROVAL FRAMEWORK

Systems and methods include a computer-implemented method for multi-stage approval. Approval scenarios are defined that include four stages including a requestor review stage, a requestor management approval stage, an owner approval stage, and a processing stage. A custom proponent code authority is generated for each principal or collection of principals to manage access and roles under their jurisdiction. The custom proponent code authority is generated for each approval scenario through a centralized identity and access management system. A requester review is performed on a request received from a requestor. The requester review is performed using a decentralized approval process. A requestor management approval of the request is performed in the requestor management approval stage. An owner approval is performed in the owner approval stage by an owner associated with owner role names mapped to role suffixes. The owner approval authorizes further processing or access to at least one resource.

TECHNICAL FIELD

The present disclosure applies to authorization processes.

BACKGROUND

Large enterprises can have complex authorization requirements for their applications and systems. Conventional systems typically do not provide centralized management and reporting capabilities for identity and access management processes. Furthermore, developing approval for identity and access management for each application is not practical or cost-effective. For this reason, application owners are usually forced to process access requests manually, e.g., using traditional forms, which can delay an employee, such as an approving authority, in achieving their task in a time-efficient way.

SUMMARY

The present disclosure describes techniques that can be used for providing centralized management and reporting capabilities for identity and access management processes. In some implementations, a computer-implemented method includes the following. Approval scenarios are defined that include four stages including a requestor review stage, a requestor management approval stage, an owner approval stage, and a processing stage. A custom proponent code authority is generated for each principal or collection of principals to manage access and roles under their jurisdiction. The custom proponent code authority is generated for each approval scenario through a centralized identity and access management system. A requester review is performed on a request received from a requestor. The requester review is performed in the requestor review stage using a decentralized approval process. A requestor management approval of the request is performed in the requestor management approval stage. An owner approval is performed in the owner approval stage by an owner associated with owner role names mapped to role suffixes. The owner approval authorizes further processing or access to at least one resource.

The previously described implementation is implementable using a computer-implemented method; a non-transitory, computer-readable medium storing computer-readable instructions to perform the computer-implemented method; and a computer-implemented system including a computer memory interoperably coupled with a hardware processor configured to perform the computer-implemented method, the instructions stored on the non-transitory, computer-readable medium.

The subject matter described in this specification can be implemented in particular implementations, so as to realize one or more of the following advantages. A solution is provided for an optimal model of authorization approvals that can work for all applications and systems in a large enterprise. The improvements and technical advantages of enhanced processes described in the present disclosure include decentralized approval processes that are flexible, optimized, and cost efficient. The present disclosure provides a solution which includes: defining approval scenarios, defining role owners, and using a naming convention for a role which provides flexibility of the role owner and flexibility in requesting based on owners. The framework of the present disclosure includes the following features. The approval framework is enhanced to provide: 1) integration with a corporate human resources system; 2) highly-flexible methods that can accommodate approval scenarios related to identity and access management processes; 3) easy configuration using the abstract scenarios for any processes; 4) reporting capabilities for any application or principals utilizing the framework; 5) design owner role name (user maintenance role) mapped to role suffixes; and 6) flexibility based on a role owner and a requesting owner.

The details of one or more implementations of the subject matter of this specification are set forth in the Detailed Description, the accompanying drawings, and the claims. Other features, aspects, and advantages of the subject matter will become apparent from the Detailed Description, the claims, and the accompanying drawings.

DETAILED DESCRIPTION

The following detailed description describes techniques for providing centralized management and reporting capabilities for identity and access management processes. Various modifications, alterations, and permutations of the disclosed implementations can be made and will be readily apparent to those of ordinary skill in the art, and the general principles defined may be applied to other implementations and applications, without departing from the scope of the disclosure. In some instances, details unnecessary to obtain an understanding of the described subject matter may be omitted so as to not obscure one or more described implementations with unnecessary detail and inasmuch as such details are within the skill of one of ordinary skill in the art. The present disclosure is not intended to be limited to the described or illustrated implementations, but to be accorded the widest scope consistent with the described principles and features.

The present disclosure describes custom techniques for accommodating approval scenarios for identity and access management processes in a large enterprise hosting a large number of applications and systems running on different platforms. Use of the techniques can ensure effective management and can reduce the cost of developing a repetitive approval process. A process is provided for effectively employing a decentralized approval model for custom objects and roles with a large number of systems, applications, and authorization objects in a large enterprise. Use of the techniques can optimize (and provide flexible framework for) different approval requirements in an enterprise to extend the capabilities of identity and access management domains in a cybersecurity framework. Optimization can be defined or measured, for example, as completing approval requirements within a time duration that is less than a pre-defined threshold time, or reducing an approval process by a pre-defined percentage of time.

Features of the process can include the at least following: 1) integration with corporate human resources (HR) systems; 2) highly flexible methods that accommodate approval scenarios related to identity and access management processes; 3) a simple and intuitive configuration using the abstract scenarios for any process; 4) reporting capabilities for any application or principals utilizing the framework. Multiple steps can be used in an optimized, distributed, multi-phase authorization approval framework, e.g., as described in the following sections.

Defining Approval Scenarios

In identity and access management processes, an approval can preferably go through at least one of four stages. The first stage is a requester review. This stage can be mandatory in case the request has been submitted on behalf of a requester. Otherwise, the stage can be skipped if the submitter is the requester.

The second stage is requester management approval. This stage is typically required in all processes and may have different levels for each process, role, user type, or other defined levels (e.g., information system analyst, supervisor, or division head).

The next stage is owner approval. Owner approval can be done, for example, either by organization or security group. For example, each group of users, business roles, variant roles, and admin accounts can be owned by different organizations or can be managed by a specific group. The owner approval stage is important to pass the approval to the right owner(s).

In some cases, manual processing is inevitable. After approval, the request can use a final stage before completion. This stage is usually a processing stage to review documents, perform manual configuration in the system, provide consultation, or perform actions on external or isolated environments.

The process of the multiple stages can include one or more (e.g., two) notifications (such as emails) which are sent to the requester. The first notification can be sent based on submission, e.g., to indicate that a request has been submitted, identifying the requestor and a date/time of the request. Another notification can be sent after the last defined approval stage for the process or after any rejection at any stage including the status of the request.

Each process can have a different approval configuration. For some processes, such as an access request, the approval can be different for each application/role, depending on the application/role approval configuration.

Defining Proponent Code

In order for an owner approval stage utilizing an owner information security analyst (ISA) group to be successful in highly-optimized process, a custom proponent code is generated for each principal or collection of principals that are mapped to a certain organization or grouped to have a similar type of authority to manage access and roles under their jurisdiction. The proponent code serves as an entry point to any principal that is willing to assume an equal privilege over a collection of roles. The proponent code has an authorization body to approve the acceptance of anyone to join the proponent code access. Upon approving that authority, the principal is mapped to the authorized proponent code(s).

Design Owner Role Named (User Maintenance Role) Mapped to Roles Suffixes

A custom definition of a role can be designed and created to map the proponent code authority (defined previous) to selected suffixes of defined roles. This role involves the use of custom objects that include a list of roles' prefixes on which the proponent code authority can control acceptance.

Roles Are Created With Defined Naming Convention and Owners

To allow for the abstraction and simplified use of the system, roles can preferably be created with a defined naming convention, e.g., as defined in a user maintenance role. This will allow the delegation to be done automatically for anyone who has the user maintenance role.

Role Catalog

Using a flexible model can allow for the same role to have multiple owners in a unique manner. The only requirement is to create a new maintenance role using the existing roles naming convention. The new maintenance role may be owned by a different owner who will be responsible for the new maintenance role.

With the flexibility of role owners, the principal requesting a role may request the role against a specific owner based on defined maintenance roles that are mapped through the naming convention. This flexibility permits individual owners to manage the authorities on decentralized manner.

Report of Authorities

Proponent code owners can receive a report on a monthly basis, with the report identifying and mapping authorized principals to their owned proponent codes. The reported information provides the owners with the ability to make decisions as to whether principals may continue to assume proponent code authority.

Renewal of Proponent Code Authority

An annual recertification is required for any principal. During this process, the owner of the proponent code can certify that the principal is qualified to maintain the proponent code authority. In addition, when a principal's organization changes, there can be a requirement to recertify the authority.

FIG.1is a block diagram showing example stages of an approval scenarios framework100, according to some implementations of the present disclosure. A first stage of the approval scenarios framework is a requester review102. The stage uses a requester110defining the person who is involved in the first stage102. An approval authority engine can be used to which all requests are routed. In the language of the approval authority engine, the requester, based on the framework, will be the first to receive the request.

A second stage of the approval scenarios framework is a requester management approval stage104. This stage includes definitions for a requester ISA112and requester management114(e.g., supervisor, division head, department manager, or vice president (VP)).

A third stage of the approval scenarios framework is an owner approval stage106, including a variant owner116. A role/access can have a variant which is an additional selection criteria. For example, a user can request to be a project manager on project A. The owner of Project A, for example, can be set in organization (org) head120defining the project's owner who is part of the approval process. The owner approval stage106includes a role/account owner118, and either an organization (org) head122or a group124(e.g., an owner, an ISA, or an associate information security analyst (AISA).

A fourth stage of the approval scenarios framework100is a processing stage108. Processor126defines a processor that is used in this stage of the approval scenarios framework100if a processor is needed in this stage. The processer108can define a group128of individuals that are responsible to process the request.

FIG.2is a screenshot200showing examples of proponent code definitions, according to some implementations of the present disclosure. The screenshot200includes a definition identifier (ID)202, a system204associated with the definition, a proponent code value206, an ISA208that owns the proponent code, and any exclusions210to this definition.

FIG.3is a screenshot300showing an example of owner to maintenance role mapping, according to some implementations of the present disclosure. The screenshot300includes a proponent code definition ID302, a system304associated with the proponent code definition ID302, a proponent code value306, an associated user maintenance role308, a description310of the associated user maintenance role, exclusions312, an indication314of whether the definition is manually handled, a deletion indicator316indicating whether the definition has been deleted, a change ID318indicating who last changed the definition, a change date320, a change time322, and an organization code324for the mapping.

FIG.4is a screenshot400showing an example of a maintenance role to role prefix mapping, according to some implementations of the present disclosure. The maintenance role to role prefix mapping includes a maintenance role name402, an authorization role check404, administrative attributes408not being used, a definition410indicating how the authorization check happens, a collection412of role prefixes, and a role prefix406.

FIG.5is a screenshot500showing examples of role definitions, according to some implementations of the present disclosure. The screenshot500includes a proponent code definition ID502, a system504associated with the role, a proponent owner code506, a role name508, a role description510, exclusions512, an indicator514indicating whether the role is based on the position of the user in the organization, an indicator516indicating if the role is sensitive, an indicator518indicating if the role is not searchable for users, an identifier520identifying who changed the role, a change date522indicating when role was changed, and a time of change524.

FIG.6is a screenshot600showing examples of requests based on owners, according to some implementations of the present disclosure. The screen provides an interface that allows users to request roles based on owners. The screenshot600includes a role name602, a role description604, an organization606that owns the role, and an option608to request the addition of the role.

FIG.7is a screenshot700showing examples of users' access, according to some implementations of the present disclosure. The screenshot700includes, in a role section702, a role name706, an indicator708indicating whether the role is no longer in use, a role description710of the role, a system712to which the role is associated, a destination systems control714, tabs716for defining other aspects of the role, a details control718to list details of the role, and a comparison control720to generate a comparison of users access with other roles (720). The screenshot700includes, in a user assignment section704, an option722to do action on multiple users at the same time, a user724who has access to the role, a user name726of the user, a start date728of the access, and an end date730of the access.

FIG.8is a flowchart of an example of a method800for implementing an approval process using a centralized identity and access management system, according to some implementations of the present disclosure. For clarity of presentation, the description that follows generally describes method800in the context of the other figures in this description. However, it will be understood that method800can be performed, for example, by any suitable system, environment, software, and hardware, or a combination of systems, environments, software, and hardware, as appropriate. In some implementations, various steps of method800can be run in parallel, in combination, in loops, or in any order.

At802, approval scenarios are defined that include four stages including a requestor review stage, a requestor management approval stage, an owner approval stage, and a processing stage. The approval scenarios can be defined using the user interfaces described with reference toFIGS.2-7, for example. From802, method800proceeds to804.

At804, a custom proponent code authority is generated for each principal or collection of principals to manage access and roles under their jurisdiction. The custom proponent code authority is generated for each approval scenario through a centralized identity and access management system. In some implementations, the custom proponent code authority is mapped to a certain organization or is grouped to have a similar type of authority. Each role can be defined by a custom role definition designed and created to map the custom proponent code authority to selected suffixes of defined roles. Each role can be associated with custom objects, each object including a list of role prefixes on which the custom proponent code authority can control acceptance. From804, method800proceeds to806.

At806, a requester review is performed on a request received from a requestor. The requester review is performed in the requestor review stage using a decentralized approval process. As an example, performing the requester review on the request received from the requestor can include using, in the decentralized approval process, an approval authority engine to which requests are routed. From806, method800proceeds to808.

At808, a requestor management approval of the request is performed in the requestor management approval stage. For example, performing the requestor management approval of the request can include obtaining an approval selected from a group consisting of a group leader approval, a division head approval, a department manager approval, and a vice president approval. For example, requestor management approval can span two stages, including using a requester ISA that is decentralized within organizations, and using requester management and varying hierarchies of approval being possible, such as through a group leader, a division head, a department manager, and a VP. The process can be implemented using an approval authority engine where all requests are routed. In the language of approval authority engine, the requester management approval, based on the framework, will receive the request to approve. From808, method800proceeds to810.

At810, an owner approval is performed in the owner approval stage by an owner associated with owner role names mapped to role suffixes. The owner approval authorizes further processing or access to at least one resource. For example, the owner can be an organization head, an owner ISA, and an owner AISA. After810, method800can stop.

In some implementations, in addition to (or in combination with) any previously-described features, techniques of the present disclosure can include the following. Outputs of the techniques of the present disclosure can be performed before, during, or in combination with wellbore operations, such as to provide inputs to change the settings or parameters of equipment used for drilling. Examples of wellbore operations include forming/drilling a wellbore, hydraulic fracturing, and producing through the wellbore, to name a few. The wellbore operations can be triggered or controlled, for example, by outputs of the methods of the present disclosure. In some implementations, customized user interfaces can present intermediate or final results of the above described processes to a user. Information can be presented in one or more textual, tabular, or graphical formats, such as through a dashboard. The information can be presented at one or more on-site locations (such as at an oil well or other facility), on the Internet (such as on a webpage), on a mobile application (or “app”), or at a central processing facility. The presented information can include suggestions, such as suggested changes in parameters or processing inputs, that the user can select to implement improvements in a production environment, such as in the exploration, production, and/or testing of petrochemical processes or facilities. For example, the suggestions can include parameters that, when selected by the user, can cause a change to, or an improvement in, drilling parameters (including drill bit speed and direction) or overall production of a gas or oil well. The suggestions, when implemented by the user, can improve the speed and accuracy of calculations, streamline processes, improve models, and solve problems related to efficiency, performance, safety, reliability, costs, downtime, and the need for human interaction. In some implementations, the suggestions can be implemented in real-time, such as to provide an immediate or near-immediate change in operations or in a model. The term real-time can correspond, for example, to events that occur within a specified period of time, such as within one minute or within one second. Events can include readings or measurements captured by downhole equipment such as sensors, pumps, bottom hole assemblies, or other equipment. The readings or measurements can be analyzed at the surface, such as by using applications that can include modeling applications and machine learning. The analysis can be used to generate changes to settings of downhole equipment, such as drilling equipment. In some implementations, values of parameters or other variables that are determined can be used automatically (such as through using rules) to implement changes in oil or gas well exploration, production/drilling, or testing. For example, outputs of the present disclosure can be used as inputs to other equipment and/or systems at a facility. This can be especially useful for systems or various pieces of equipment that are located several meters or several miles apart, or are located in different countries or other jurisdictions.

FIG.9is a block diagram of an example computer system900used to provide computational functionalities associated with described algorithms, methods, functions, processes, flows, and procedures described in the present disclosure, according to some implementations of the present disclosure. The illustrated computer902is intended to encompass any computing device such as a server, a desktop computer, a laptop/notebook computer, a wireless data port, a smart phone, a personal data assistant (PDA), a tablet computing device, or one or more processors within these devices, including physical instances, virtual instances, or both. The computer902can include input devices such as keypads, keyboards, and touch screens that can accept user information. Also, the computer902can include output devices that can convey information associated with the operation of the computer902. The information can include digital data, visual data, audio information, or a combination of information. The information can be presented in a graphical user interface (UI) (or GUI).

The computer902can serve in a role as a client, a network component, a server, a database, a persistency, or components of a computer system for performing the subject matter described in the present disclosure. The illustrated computer902is communicably coupled with a network930. In some implementations, one or more components of the computer902can be configured to operate within different environments, including cloud-computing-based environments, local environments, global environments, and combinations of environments.

The computer902can receive requests over network930from a client application (for example, executing on another computer902). The computer902can respond to the received requests by processing the received requests using software applications. Requests can also be sent to the computer902from internal users (for example, from a command console), external (or third) parties, automated applications, entities, individuals, systems, and computers.

Each of the components of the computer902can communicate using a system bus903. In some implementations, any or all of the components of the computer902, including hardware or software components, can interface with each other or the interface904(or a combination of both) over the system bus903. Interfaces can use an application programming interface (API)912, a service layer913, or a combination of the API912and service layer913. The API912can include specifications for routines, data structures, and object classes. The API912can be either computer-language independent or dependent. The API912can refer to a complete interface, a single function, or a set of APIs.

The service layer913can provide software services to the computer902and other components (whether illustrated or not) that are communicably coupled to the computer902. The functionality of the computer902can be accessible for all service consumers using this service layer. Software services, such as those provided by the service layer913, can provide reusable, defined functionalities through a defined interface. For example, the interface can be software written in JAVA, C++, or a language providing data in extensible markup language (XML) format. While illustrated as an integrated component of the computer902, in alternative implementations, the API912or the service layer913can be stand-alone components in relation to other components of the computer902and other components communicably coupled to the computer902. Moreover, any or all parts of the API912or the service layer913can be implemented as child or sub-modules of another software module, enterprise application, or hardware module without departing from the scope of the present disclosure.

The computer902includes an interface904. Although illustrated as a single interface904inFIG.9, two or more interfaces904can be used according to particular needs, desires, or particular implementations of the computer902and the described functionality. The interface904can be used by the computer902for communicating with other systems that are connected to the network930(whether illustrated or not) in a distributed environment. Generally, the interface904can include, or be implemented using, logic encoded in software or hardware (or a combination of software and hardware) operable to communicate with the network930. More specifically, the interface904can include software supporting one or more communication protocols associated with communications. As such, the network930or the interface's hardware can be operable to communicate physical signals within and outside of the illustrated computer902.

The computer902includes a processor905. Although illustrated as a single processor905inFIG.9, two or more processors905can be used according to particular needs, desires, or particular implementations of the computer902and the described functionality. Generally, the processor905can execute instructions and can manipulate data to perform the operations of the computer902, including operations using algorithms, methods, functions, processes, flows, and procedures as described in the present disclosure.

The computer902also includes a database906that can hold data for the computer902and other components connected to the network930(whether illustrated or not). For example, database906can be an in-memory, conventional, or a database storing data consistent with the present disclosure. In some implementations, database906can be a combination of two or more different database types (for example, hybrid in-memory and conventional databases) according to particular needs, desires, or particular implementations of the computer902and the described functionality. Although illustrated as a single database906inFIG.9, two or more databases (of the same, different, or combination of types) can be used according to particular needs, desires, or particular implementations of the computer902and the described functionality. While database906is illustrated as an internal component of the computer902, in alternative implementations, database906can be external to the computer902.

The computer902also includes a memory907that can hold data for the computer902or a combination of components connected to the network930(whether illustrated or not). Memory907can store any data consistent with the present disclosure. In some implementations, memory907can be a combination of two or more different types of memory (for example, a combination of semiconductor and magnetic storage) according to particular needs, desires, or particular implementations of the computer902and the described functionality. Although illustrated as a single memory907inFIG.9, two or more memories907(of the same, different, or combination of types) can be used according to particular needs, desires, or particular implementations of the computer902and the described functionality. While memory907is illustrated as an internal component of the computer902, in alternative implementations, memory907can be external to the computer902.

The application908can be an algorithmic software engine providing functionality according to particular needs, desires, or particular implementations of the computer902and the described functionality. For example, application908can serve as one or more components, modules, or applications. Further, although illustrated as a single application908, the application908can be implemented as multiple applications908on the computer902. In addition, although illustrated as internal to the computer902, in alternative implementations, the application908can be external to the computer902.

The computer902can also include a power supply914. The power supply914can include a rechargeable or non-rechargeable battery that can be configured to be either user-or non-user-replaceable. In some implementations, the power supply914can include power-conversion and management circuits, including recharging, standby, and power management functionalities. In some implementations, the power supply914can include a power plug to allow the computer902to be plugged into a wall socket or a power source to, for example, power the computer902or recharge a rechargeable battery.

There can be any number of computers902associated with, or external to, a computer system containing computer902, with each computer902communicating over network930. Further, the terms “client,” “user,” and other appropriate terminology can be used interchangeably, as appropriate, without departing from the scope of the present disclosure. Moreover, the present disclosure contemplates that many users can use one computer902and one user can use multiple computers902.

For example, in a first implementation, a computer-implemented method includes the following. Approval scenarios are defined that include four stages including a requestor review stage, a requestor management approval stage, an owner approval stage, and a processing stage. A custom proponent code authority is generated for each principal or collection of principals to manage access and roles under their jurisdiction. The custom proponent code authority is generated for each approval scenario through a centralized identity and access management system. A requester review is performed on a request received from a requestor. The requester review is performed in the requestor review stage using a decentralized approval process. A requestor management approval of the request is performed in the requestor management approval stage. An owner approval is performed in the owner approval stage by an owner associated with owner role names mapped to role suffixes. The owner approval authorizes further processing or access to at least one resource.

A first feature, combinable with any of the following features, the method further including mapping the custom proponent code authority to a certain organization or grouped to have a similar type of authority.

A second feature, combinable with any of the previous or following features, where performing the requester review on the request received from the requestor includes using, in the decentralized approval process, an approval authority engine to which requests are routed.

A third feature, combinable with any of the previous or following features, where performing the requestor management approval of the request includes obtaining an approval selected from a group consisting of a group leader approval, a division head approval, a department manager approval, and a vice president approval.

A fourth feature, combinable with any of the previous or following features, where the owner is selected from a group consisting of an organization head, an owner information security analyst (ISA), and an owner associate information security analyst (AISA).

A fifth feature, combinable with any of the previous or following features, where each role is defined by a custom role definition designed and created to map the custom proponent code authority to selected suffixes of defined roles.

A sixth feature, combinable with any of the previous or following features, where each role is associated with custom objects, each object including a list of role prefixes on which the custom proponent code authority can control acceptance.

In a second implementation, a non-transitory, computer-readable medium stores one or more instructions executable by a computer system to perform operations including the following. Approval scenarios are defined that include four stages including a requestor review stage, a requestor management approval stage, an owner approval stage, and a processing stage. A custom proponent code authority is generated for each principal or collection of principals to manage access and roles under their jurisdiction. The custom proponent code authority is generated for each approval scenario through a centralized identity and access management system. A requester review is performed on a request received from a requestor. The requester review is performed in the requestor review stage using a decentralized approval process. A requestor management approval of the request is performed in the requestor management approval stage. An owner approval is performed in the owner approval stage by an owner associated with owner role names mapped to role suffixes. The owner approval authorizes further processing or access to at least one resource.

A first feature, combinable with any of the following features, the operations further including mapping the custom proponent code authority to a certain organization or grouped to have a similar type of authority.

A second feature, combinable with any of the previous or following features, where performing the requester review on the request received from the requestor includes using, in the decentralized approval process, an approval authority engine to which requests are routed.

A third feature, combinable with any of the previous or following features, where performing the requestor management approval of the request includes obtaining an approval selected from a group consisting of a group leader approval, a division head approval, a department manager approval, and a vice president approval.

A fourth feature, combinable with any of the previous or following features, where the owner is selected from a group consisting of an organization head, an owner information security analyst (ISA), and an owner associate information security analyst (AISA).

A fifth feature, combinable with any of the previous or following features, where each role is defined by a custom role definition designed and created to map the custom proponent code authority to selected suffixes of defined roles.

A sixth feature, combinable with any of the previous or following features, where each role is associated with custom objects, each object including a list of role prefixes on which the custom proponent code authority can control acceptance.

In a third implementation, a computer-implemented system includes one or more processors and a non-transitory computer-readable storage medium coupled to the one or more processors and storing programming instructions for execution by the one or more processors. The programming instructions instruct the one or more processors to perform operations including the following. Approval scenarios are defined that include four stages including a requestor review stage, a requestor management approval stage, an owner approval stage, and a processing stage. A custom proponent code authority is generated for each principal or collection of principals to manage access and roles under their jurisdiction. The custom proponent code authority is generated for each approval scenario through a centralized identity and access management system. A requester review is performed on a request received from a requestor. The requester review is performed in the requestor review stage using a decentralized approval process. A requestor management approval of the request is performed in the requestor management approval stage. An owner approval is performed in the owner approval stage by an owner associated with owner role names mapped to role suffixes. The owner approval authorizes further processing or access to at least one resource.

A first feature, combinable with any of the following features, the operations further including mapping the custom proponent code authority to a certain organization or grouped to have a similar type of authority.

A second feature, combinable with any of the previous or following features, where performing the requester review on the request received from the requestor includes using, in the decentralized approval process, an approval authority engine to which requests are routed.

A third feature, combinable with any of the previous or following features, where performing the requestor management approval of the request includes obtaining an approval selected from a group consisting of a group leader approval, a division head approval, a department manager approval, and a vice president approval.

A fourth feature, combinable with any of the previous or following features, where the owner is selected from a group consisting of an organization head, an owner information security analyst (ISA), and an owner associate information security analyst (AISA).

A fifth feature, combinable with any of the previous or following features, where each role is defined by a custom role definition designed and created to map the custom proponent code authority to selected suffixes of defined roles.

Computers suitable for the execution of a computer program can be based on one or more of general and special purpose microprocessors and other kinds of CPUs. The elements of a computer are a CPU for performing or executing instructions and one or more memory devices for storing instructions and data. Generally, a CPU can receive instructions and data from (and write data to) a memory.

Graphics processing units (GPUs) can also be used in combination with CPUs. The GPUs can provide specialized processing that occurs in parallel to processing performed by CPUs. The specialized processing can include artificial intelligence (AI) applications and processing, for example. GPUs can be used in GPU clusters or in multi-GPU computing.

A computer can include, or be operatively coupled to, one or more mass storage devices for storing data. In some implementations, a computer can receive data from, and transfer data to, the mass storage devices including, for example, magnetic, magneto-optical disks, or optical disks. Moreover, a computer can be embedded in another device, for example, a mobile telephone, a personal digital assistant (PDA), a mobile audio or video player, a game console, a global positioning system (GPS) receiver, or a portable storage device such as a universal serial bus (USB) flash drive.

Furthermore, any claimed implementation is considered to be applicable to at least a computer-implemented method; a non-transitory, computer-readable medium storing computer-readable instructions to perform the computer-implemented method; and a computer system including a computer memory interoperably coupled with a hardware processor configured to perform the computer-implemented method or the instructions stored on the non-transitory, computer-readable medium.