Patent Grant
9558334
Aspects of the present disclosure generally relate to provisioning access to computing resources and particularly relate to provisioning access to computing resources using an identity access management data model.
Identity and access management (IAM) refers to the processes, technologies, and policies for managing digital identities and controlling how those identities can be used to access resources. For large business entities having thousands of employees and complex computer systems, IAM can be a challenge.
As personnel join, leave, and move throughout the enterprise, access rights to various computing resources may need to be updated, e.g., to add, remove, or modify access rights. Furthermore, periodic access reviews may need to be performed to ensure that access rights for personnel do not exceed the scope of their authority. In other words, access reviews may be used to determine whether employees can access only those resources necessary to perform their job duties. Moreover, it may also be important to ensure personnel are not provided with/incompatible access rights—combinations of access rights that would allow personnel to carry out incompatible tasks.
These aspects of IAM may be difficult in current implementations of IAM systems. In particular, current IAM systems may require business personnel to request changes to access rights in terms of the technical infrastructure underlying the enterprise computer system. Furthermore, provisioning access rights in conventional systems may be a manual process, which can lead to mistakes and inconsistencies in provisioned access rights. Erroneously provisioned access rights may lead to users having access to computing resources outside the scope of their authority. Additionally, current IAM systems may require business personnel to perform access reviews also in technical terms. Business personnel, however, may not be familiar nor concerned with the technical details of the enterprise computer system. As a result, business personnel may have difficulty requesting changes to access rights and conducting access reviews. Therefore, a need exists for improved approaches to submitting access requests and conducting access reviews.
The following presents a simplified summary of various aspects described herein. This summary is not an extensive overview, and is not intended to identify key or critical elements or to delineate the scope of the claims. The following summary merely presents some concepts in a simplified form as an introductory prelude to the more detailed description provided below.
A first aspect described provides a computer-implemented method of provisioning access rights to physical computing resources. An access request handler may receive an access request and identify a set of logical permissions based, at least in part, on the access request. The access request handler may derive a set of logical entitlements based, at least in part, on the set of logical permissions. An entitlement translator may translate the set of logical entitlements to a physical entitlement specification. The logical entitlements may be translated to a physical entitlement specification based on a set of physical permission specifications respectively associated with the set of logical permissions. A physical permission specification may be obtained by mapping a logical permission associated with a logical computing resource to one or more physical permissions respectively associated with one or more physical computing resources. An access control manager may then provision access rights to at least one physical computing resource indicated in the physical entitlement specification.
A second aspect described also provides a system for provisioning access rights to physical computing resources. The system may include a processor and a data store that implements an IAM data model. The data store may store a set of logical computing resource records corresponding to one or more logical computing resources. The data store may also store a set of physical computing resource records corresponding to one or more physical computing resources. Through the IAM data model, the logical computing resource records may be respectively associated with one or more of the physical computing resource records. The system may also include an access request handler, an entitlement translator, and an access control manager as described above. The system may further include a separation-of-duties verifier that determines whether a separation-of-duties violation would result upon provisioning the requested access rights to the physical computing resources. Notification of the separation-of-duties violation may be provided in response to a determination that the violation would result if the access rights were provisioned. Other aspects described provide non-transitory computer-readable media having instructions stored thereon. The instructions, when executed by a processor, cause the processor to perform steps for provisioning access rights to physical computing resources as described above.
The access request may specify a business unit, a business activity, a business task, or a logical permission. In this regard, the set of logical permissions identified by the access request handler may include logical permissions associated with a business unit, logical permissions associated with the business tasks of a specified business activity, the logical permissions associated with a specified business task, or the specified logical permission. Access rights may also be provisioned for each user associated with a specified business unit as well as for each additional user associated with a related business unit. A related business unit may be identified based on a recursion direction and a recursion level specified in the access request. The access request may also specify a physical permission specification, and access rights may be provisioned for each physical computing resource identified in the physical permission specification.
A third aspect described herein provides a non-transitory computer-readable medium having instructions that, when executed by a processor, cause the processor to perform steps corresponding to various aspects described above.
These and other aspects of the present disclosure will be apparent in view of the detailed description provided below.
Aspects of the disclosure may be implemented in certain parts, steps, and embodiments that will be described in detail in the following description and illustrated in the accompanying drawings in which like reference numerals indicate similar elements. It will be appreciated with the benefit of this disclosure that the steps illustrated in the accompanying figures may be performed in other than the recited order and that one or more of the steps disclosed may be optional. It will also be appreciated with the benefit of this disclosure that one or more components illustrated in the accompanying figures may be positioned in other than the disclosed arrangement and that one or more of the components illustrated may be optional.
Aspects of the present disclosure are directed towards provisioning access rights to physical computing resources and reviewing such access rights. Access requests and access reviews may be conducted with the assistance of an identity access management (IAM) system that implements an IAM data model. A data model for organizing and establishing relationships between IAM data is described in U.S. Provisional Patent App. No. 61/740,205 and U.S. patent application Ser. No. 13/801,314 each of which are incorporated in this disclosure in their entirety. The access request and access review features described below illustrate one of the many advantages of implementing a common IAM data model at the computer system of an enterprise. Aspects of the disclosure below may be described in the context of business enterprises and the computer systems of such business enterprises. It will be appreciated, however, that aspects of the present disclosure may selectively implemented at the computer systems of any type of enterprise.
The approaches to identity access management described below advantageously improve the process of requesting access rights at an enterprise computer system as well as the process of conducting access reviews. Not only do the improved approaches to IAM provide more efficiency within the enterprise, the approaches advantageously provide more security by reducing the possibility of unauthorized access to physical computing resources at the enterprise computer system.
In particular, the IAM system and corresponding IAM data model described in the present disclosure divide aspects of IAM into logical and physical aspects. The logical aspects are described in business terms familiar to the business personnel of the enterprise. The physical aspects are described in the physical or technical terms familiar to technology personnel. The IAM system and IAM data model of the present disclosure maintain a correspondence between the logical aspects and the physical aspects of the computer systems of an enterprise. As discussed in further detail below, the IAM system and IAM data model may include entities representing logical computing resources (“logical resources”) and corresponding physical computing resources (“physical resources”), logical permissions and corresponding physical permissions, logical entitlements and corresponding physical entitlements, and other entities representing logical and physical aspects of identity access management.
In this way, business personnel may submit access requests and conduct access reviews with reference to the logical aspects of IAM and with reference to the business terms familiar to the business personnel. The correspondence between the logical and physical aspects may thus allow technology personnel to fulfill access requests with reference to the physical aspects of IAM and with reference to the technical terms of the enterprise computer system. As a result, business personnel need not understand the underlying infrastructure of the enterprise computer system when submitting access requests and conducting access reviews. The IAM system advantageously converts the logical aspects to corresponding physical aspects in order to fulfill the access requests. In addition, the IAM system converts the physical aspects to corresponding logical aspects for access reviews. These and other aspects will be appreciated with additional reference to the details set forth below.
It is to be understood that the phraseology and terminology used herein are for the purpose of description and should not be regarded as limiting. Rather, the phrases and terms used herein are to be given their broadest interpretation and meaning. The use of “including” and “comprising” and variations thereof is meant to encompass the items listed thereafter and equivalents thereof as well as additional items and equivalents thereof. The use of the terms “mounted,” “connected,” “coupled,” “positioned,” “engaged” and similar terms, is meant to include both direct and indirect mounting, connecting, coupling, positioning and engaging. In addition, “set” as used in this description refers to a collection that may include one element or more than one element. Moreover, aspects of the disclosure may be implemented in non-transitory computer-readable media having instructions stored thereon that, when executed by a processor, cause the processor to perform various steps described in further detail below. As used in this description, non-transitory computer-readable media refers to all computer-readable media with the sole exception being a transitory propagating signal.
I/O 109 may include a microphone, keypad, touch screen, and/or stylus through which a user of the IAM system 101 may provide input, and may also include one or more of a speaker for providing audio output and a video display device for providing textual, audiovisual and/or graphical output. Software may be stored within memory 115 and/or storage to provide instructions to processor 103 for enabling the system 101 to perform various functions. For example, memory 115 may store software used by the system 101, such as an operating system 117, application programs 119, and an associated database 121. Processor 103 and its associated components may allow the system 101 to run a series of computer-readable instructions to process and respond to access requests and to facilitate access reviews.
The system 101 may operate in a networked environment supporting connections to one or more remote computers, such as terminals 141 and 151. The terminals 141 and 151 may be personal computers or servers that include many or all of the elements described above relative to the system 101. Alternatively, terminal 141 and/or 151 may be a data store that is affected by the backup and retention policies stored on the system 101. The network connections depicted in
Additionally, one or more application programs 119 used by the IAM system 101 according to an illustrative embodiment of the disclosure may include computer executable instructions for invoking functionality related to processing and responding to access requests and to facilitating access reviews.
The transaction analysis system 101 and/or terminals 141 or 151 may also be mobile terminals, such as smart phones, personal digital assistants (PDAs), and the like including various other components, such as a battery, speaker, and antennas (not shown).
The disclosure is operational with numerous other general purpose or special purpose computer system environments or configurations. Examples of well-known computer systems, environments, and/or configurations that may be suitable for use with the disclosure include, but are not limited to, personal computers, server computers, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, and distributed computing environments that include any of the above systems or devices, and the like.
The disclosure may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, and the like that perform particular tasks or implement particular abstract data types. The disclosure may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked, for example, through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.
Referring to
Computer network 203 may be any suitable computer network including the Internet, an intranet, a wide-area network (WAN), a local-area network (LAN), a wireless network, a digital subscriber line (DSL) network, a frame relay network, an asynchronous transfer mode (ATM) network, a virtual private network (VPN), or any combination of any of the same. Communications links 202 and 205 may be any communications links suitable for communicating between workstations 201 and the transaction analysis system 204, such as network links, dial-up links, wireless links, hard-wired links, and the like.
The disclosure that follows in the figures may be implemented by one or more of the components in
Referring now to
The IAM system 302 may be employed to process and fulfill access requests by provisioning access rights to the computing components of the computer system 300, e.g., the physical computing resources. Accordingly, the data store 304 may also store access request records 322 and provisioning records 324. Provisioning records 324 may also be referred to as provisioned physical entitlements that indicate the physical computing resources a user account has been provisioned with access rights to. As discussed in further detail below, access request records 322 and provisioning records 324 may be utilized to reconcile access rights as requested with access rights as provisioned. If the access rights provisioned do not match the access rights requested, a reconciliation exception may be generated. The data store 304 may also store reconciliation exceptions 326 that describe the disparity between access rights as requested and access rights as provisioned as shown by way of example in
The IAM system 302 also includes various modules for receiving and processing access requests and provisioning access rights to physical resources based on those access requests. The IAM system 302, in this example, includes: a resource data miner 328 that, in operation, processes source material to identify logical resources; a resource mapper 330 that, in operation, maps logical resources to physical resources; a resource assigner 332 that, in operation, assigns logical resources to business tasks; an access request handler 334 that, in operation, processes access requests and initiates the process of adjusting access rights; an entitlement translator 336 that, in operation, translates logical entitlements into physical entitlements; a separation-of-duties (SoD) verifier 338 that, in operation, verifies requested access rights are not incompatible with existing access rights for a user; an access control manager 340 that, in operation, initiates an adjustment of access rights to a resource for a user account or user account group; and reconciler 342 that, in operation, reconciles access rights as requested with access rights as provisioned. These modules 328-342 will be discussed in further detail below.
The IAM system 302 may be in signal communication via a network 344 with one or more workstations 346 and one or more computing resources 348. The workstations 346 may provide various interfaces (e.g., web-based portals or dashboards) for submitting access requests to the IAM system 302 and conducting access reviews. The computing resources 348 may represent the physical resources to which access is requested. In this regard, the computing resources 348 may include: information systems; software applications and programs; services; computing devices such as servers and workstations; network devices such as switches and routers; file systems; databases; and other types of physical computing resources. The IAM system 302 may receive access requests from the workstations 346 and process the access requests to provision access to one or more of the computing resources 348. As discussed in further detail below, the components of the IAM system may utilize the IAM data model to carry out their respective functions.
In
The first stage in implementing an IAM system 302 for processing access requests involves establishing the IAM system itself and initializing the data store 304 by populating the IAM data model with information relating to the logical resources, physical resources, and business architecture of the enterprise. In this regard, the resource data miner 328 may receive and process source material 402 to identify the logical resources of the enterprise. The source material 402 may include, e.g., job aids, training materials, procedure manuals, and other types of materials that describe and define the job functions of the employees of the enterprise. The resource data miner 328 may be configured to extract and analyze the text of the source material 402 in order to identify a list 404 of logical resources and associated logical permissions. An IAM developer may review the list 404 of logical resources and permissions generated by the resource data miner 328 and edit the list, e.g., to revise logical resource names, remove proposed logical resources, and perform other types of edits to refine the list of logical resources and permission for the enterprise. Once the list 404 of logical resources and permissions is acceptable, logical computing resource records respectively corresponding to the set of logical resources and permissions may be created and stored in the data store 304. The data store 304 may organize the logical computing resource records in accordance with the IAM data model 306.
Logical resources refer to resources that are visible and accessible to an end user. Logical resources are implemented using physical resources that are not visible to the end user. An example of a logical resource includes the set of one or more screen interfaces utilized to maintain a customer account. Logical resources may be associated with logical permissions. Logical permissions refer to the set of access rights for a logical resource. In this regard, a logical permission may be understood as a pairing of a logical resource and an access right. Using the example of a customer account maintenance screen, examples of access rights include an access right to read information at the customer account maintenance screen and an access right to write information at the customer account maintenance screen. It will be appreciated that some end users may have the ability to read information at the customer account maintenance screen but not the ability to write information at the customer account maintenance screen. One example logical permission may thus be the combination of the read access right and the customer account maintenance screen.
In a similar fashion, information 406 describing the computer system architecture may be utilized to generate a list 408 of physical computing resources and corresponding physical permissions. Physical resources refer to computing resources that have been deployed at a computer system 300 of an enterprise. Examples of physical resources include transactions of a transaction server, files, and database tables. Examples of physical computing resources also include computing devices and systems such as servers, gateways, workstations, databases, and other types of computing devices and systems. Multiple physical resources may correspond to a single logical resource. For example, a logical resource may include a customer maintenance screen at which an end user may read and write customer profile and account information. Multiple physical resources may be associated with the customer maintenance screen including, e.g., the transaction used to invoke the customer maintenance screen, the transaction used to query the customer database for account and profile information, the computing device that hosts the customer database, the customer database itself, and the one or more database tables that organize customer profile and account information.
Physical permissions refer to the set of access rights for a physical resource. A physical permission is thus associated with a corresponding physical resource. As noted above, access rights may include the ability to read, write, or execute. Examples of physical permissions thus include the ability to execute a transaction at a transaction server, the ability to read a file stored at a data store, and the ability to write to a database table of a database. Examples of physical permissions may also include the ability to access various computing devices and systems such as those mentioned above. An access control manager may provide access control functionality at the computer system of the enterprise. Suitable computer security systems that provide access control functionality (e.g., authentication and authorization) and auditing functionality are commercially available and may be selectively employed.
Referring back to
Business tasks are associated with logical permissions, which thus indicate the logical resources used to carry out the business task. It will therefore be appreciated that a business activity may also be associated with logical resources and logical permissions through the business tasks of the business activity. Likewise, a business process and a business role may be associated with logical resources and logical permissions through the respective business activities of the business process and business role. In this way, the set of logical resources and permissions for a business activity, business process, and business role may also be advantageously determined through the IAM data model. Moreover, it will be appreciated that business tasks, activities, processes, and roles are part of the business architecture of the enterprise. In order to physically implement these aspects of the business architecture, the business tasks, activities, processes, and roles may be associated with one or more user account groups at the computer system 300 of the enterprise. More particularly, the logical aspects of IAM that relate to individuals, business roles, activities, and tasks may be implemented in the physical context as user accounts and user account groups. User accounts may be associated with one or more user account groups, and user account groups may be associated with other user account groups. In this way, a user account group that corresponds to a business role may be composed of groups corresponding to business activities.
As seen in
In one example, a logical resource may include customer maintenance screens visible and accessible to an end user at a workstation. The corresponding physical resources may include the customer maintenance transactions available at a transaction server used to update a customer profile. Each transaction may be associated with a unique transaction code. Accordingly, the physical permission specification 414, in this example, may be a mapping of the appropriate transaction codes to the customer maintenance screens. Similar mappings may be utilized to map the customer maintenance screen to a machine that hosts the customer database, the customer database itself, and the customer tables of the customer database. In order to provide the end user with access to the logical resources, the IAM system 302 may provision access rights based on the physical permission specification 414. In this example, the IAM system 302 may provision access rights for the physical resources indicated in the physical permission specification 414.
As also seen in
Having determined the resources, permissions, and business architecture for the enterprise, the IAM system 302 may receive and process access requests 418. The access request 418 may include information identifying, e.g., an access request type, an access request action, a requestor, a requestee, and a logical resource. A requestor may submit an access request based on, e.g., a business role, a business activity, a logical permission, a business unit, a physical permission specification, and other IAM or business architecture elements. The access request type specified in the access request thus identifies the basis for the access request. The access request action refers to the set of requested access rights, e.g., add, suspend, and revoke. Other types of access rights will be appreciated including create, add, provision, suspend, disable, remove, de-provision, modify, reinstate, activate, terminate, delete, enable, re-enable, and other types of access rights. Therefore, it will be appreciated that an access request refers to a change in access rights, which may include changing the access rights to a physical resource such that a user account may access the physical resource or removing access rights such that the user account cannot access the physical resource. The requestor information in the access request identifies the entity that submitted the access request, in other words, the user requesting the change to the access rights for the requestee. The requestor may be another user or a service or component of the enterprise computer system. The requestee refers to the entity for which the access rights should be changed. The specified requestee may be a single user, a group of users associated with a particular business role, a group of users associated with a particular business activity, or a service or component of the enterprise computer system. A requestee may also be a service or machine, and an access request may therefore request a change in access rights for the service or machine.
The IAM system 302 may also store respective records for each access request. These records may thus be referred to as access request records (322 in
Referring back to
In some example implementations, the access request handler 334 may be configured to provide an access request to one or more reviewers for review and approval. If a reviewer does not approve the access request, the access request handler 334 may close the access request and notify the requestor that the access request was not approved. In some example implementations, the access request handler 334 may also pass the access request to a separation-of-duties (SoD) verifier 338 to confirm that the access request, if granted, would not result in a SoD violation. An SoD violation may occur where the access request, if granted, would associate incompatible business tasks with the end user. Incompatible business tasks refer to business tasks that should not be performed by the same person for reasons of security, integrity, or propriety. Accordingly, identifying incompatible business tasks allows for the identification of incompatible logical permissions through the IAM data model. If two business tasks are identified as incompatible, then, in some example implementations, the logical permissions respectively associated with those business tasks may be identified as incompatible logical permissions. The IAM data model 306 that organizes the IAM data of the IAM system 302, may include elements to associate business tasks such that the business tasks are identified as incompatible. It will be appreciated that these elements advantageously allow for a quick and efficient approach to determining when an access request would result in incompatible business tasks assigned to an end user. Separation-of-duties verification checks will be discussed in further detail below.
The access request handler 338 accepts as input the list 404 of logical resources and corresponding logical permissions. The access request handler 338 may thus identify the logical permissions for the logical resource specified in the access request 418 by matching the specified logical resource to the logical resource listed in the list 404 of logical resources and permissions. Based on the access request 418 and the list 404 of logical resources and permissions, the access request handler 338 may derive and produce a set 420 of logical entitlements. Like resources and permissions, entitlements have both a logical and a physical aspect. A logical entitlement refers to the pairing of a logical permission and a user account (or user account group). Stated differently, a logical entitlement refers to a logical permission that is associated with a user account (or user account group). A physical entitlement refers to the pairing of a physical permission and a user account (or user account group). Stated differently, a physical entitlement refers to a physical permission that is associated with a user account (or user account group). A physical entitlement may also be referred to as an access control list. Moreover, when a user account is associated with a physical permission, the user account may be described as having a direct entitlement; and when the user account is associated with a group that is associated with the physical permission, the user account may be described as having an indirect entitlement.
In some circumstances, an individual may be assigned to a new business role. In physical terms, the user account associated with the individual may be assigned to or associated with the user account group corresponding to the business role. To provision access rights to the physical resources associated with the business role, an access request 418 may specify a business role for the user. In this example, the access request handler 334 may also receive the list of business entities 416 in order to identify the associated business activities, business tasks, and logical permissions associated with the requested business role. The access request handler may thus generate or construct the logical entitlements 420 for the access request 418 based on the logical permissions associated with the specified business role. In a similar fashion, the access request may specify a business process, business activity, or business task. The access request handler 334 may likewise generate or construct the logical entitlements 420 based on the business process, business activity, or business task specified in the access request 418.
The entitlement translator 336, in this example, translates the logical entitlements 420 associated with the access request 418 into a physical entitlement specification 422 that identifies a set of physical entitlements corresponding to the logical entitlements 420. The entitlement translator accepts as input the logical entitlements 420 associated with an access request 418 and the respective physical permission specifications 414 corresponding to the logical permissions of the logical entitlements. Through the physical permission specification 414, the entitlement translator 336 may identify the physical permissions associated with the logical permissions of the logical entitlements 420 for the access request 418. Stated differently, the entitlement translator 336 determines a set of physical entitlements based on the logical entitlements 420 generated by the access request handler 334 and the physical permission specifications 414 associated with the logical permissions of those logical entitlements. The physical entitlement specification 422 thus identifies the set of physical entitlements. It will be appreciated that the physical entitlement specification 422 includes the physical permissions that, if provisioned, would allow the user account of the requestee to access the physical resources associated with the logical resources specified in the access request 418. As noted above, an access request 418 may indicate that access rights should be revoked for the requestee. Accordingly, the physical permission specification 422 may also include physical permissions that, if de-provisioned, would prevent the user account of the requestee from accessing the physical resources associated with the logical resource specified in the access request.
The entitlement translator 336 may forward the physical entitlement specification 422 to the access control manager 340. The access control manager 340 may then adjust the access rights to the physical resources based on the physical entitlement specification 422. The access control manager 340 may be in signal communication with resource managers 424 that respectively manage access to respective physical resources 426. A resource manager 424 may be, e.g., a system-level or application-level function that manages access to one or more physical resources 426. Examples of resource managers and corresponding physical resources include, e.g., an operating system file manager that manages access to files and file systems, a database management system that manages access to database tables and views, and an application that uses application-level security to control access to application programs. A resource manager may also be referred to as a platform. The access control manager 340 may thus initiate provisioning or de-provisioning of access rights by interacting with one or more resource managers 424. The access control manager 340 may initiate an adjustment of access rights based on the physical entitlement specification 422 that identifies the physical resources 426.
The access control manager 340 and/or the resource managers 424 may also generate records identifying provisioned physical entitlements 324. The records for the provisioned physical entitlements 324 may thus identify the access rights as provisioned. Through the association with the physical entitlement specification 422, the provisioned physical entitlements 324 may also be associated with the access request 418. Accordingly, a provisioned physical entitlement may be traceable back to the access request 418. If the provisioned physical entitlement cannot be traced back to an access request (e.g., during an access review), then this may be an indication that access rights were erroneously provisioned for a user account. Upon identifying access rights that cannot be traced back to an access request, remedial measures may be taken to address the error such as, e.g., de-provisioning the physical entitlement.
It will also be appreciated that the provisioned physical entitlements 324 may be compared to the physical entitlement specification 422 in order to determine whether the physical entitlements as provisioned match the physical entitlements as specified. If the physical entitlements as provisioned do not match the physical entitlements as specified, then remedial measures may also be taken to align existing access rights for a user account with the access rights originally specified. In this regard, a reconciler 342 may accept as input the physical entitlement specification 422 and the provisioned physical entitlements 324, e.g., the current physical resources the account has access to. The reconciler may compare the physical entitlement specification 422 to the current physical resources accessible by a user account.
If a current physical resource accessible by a user account cannot be located in one of the physical entitlement specifications 422, the reconciler 342 may determine the user account is not authorized to access the physical resource. In turn, the reconciler 342 may generate a reconciliation exception 326. The data store 304 of the IAM system 302 may store records of reconciliation exceptions 326. A reconciliation exception 326 may indicate the access rights and physical resource that cannot be found in the physical entitlement specifications associated with the user account. It will be appreciated that the reconciler 342 may generate a reconciliation exception 326 when a physical entitlement was provisioned but not specified as well as when a physical entitlement was specified but not provisioned. In some example implementations, the reconciler 342 may be configured to respond to the reconciliation exception 326 by automatically generating a new access request 418. The reconciler 342 may submit the new access request 418 to the access request handler 334 as described above. The new access request 418 may, e.g., request that access rights be provisioned for physical entitlements that were not (but should have) been provisioned. The new access request 418 may also, e.g., request that access rights be revoked for physical resources that were (but should not have been) provisioned. In this way, the IAM system 302 may advantageously manage at least some of the access rights in an automated fashion. The reconciler may also, in some example implementations, respond to the reconciliation exception by notifying (e.g., via email) a reviewer of the reconciliation exception.
In view of this disclosure reconciling physical resources refers to determining whether a user account has access to the physical resources specified in the physical entitlement specifications for the user account and whether the user account has access to physical resources that the physical entitlement specifications do not specify. Physical resources that are specified in the physical entitlement specifications for a user account may be referred to as authorized physical resources. In some circumstances, a user account may be authorized to access a physical resource but has not yet been provisioned with access rights to the physical resource such that the physical resource the user account is entitled to is not yet accessible to the user account. Authorized physical resources that are not yet accessible to the user account may be referred to as pending physical resources. In contrast, physical resources that are accessible to a user account but are not specified in any of the physical entitlement specifications for the user account may be referred to as unauthorized computing resources. It will thus be appreciated that the reconciliation exception may identify the physical resource associated with the reconciliation exception as well as whether the physical resource is an unauthorized physical resource or a pending physical resource. If the physical resource is an unauthorized physical resource, the reconciler may generate a new access request to revoke the access rights to the unauthorized physical resource. If the physical resource is a pending physical resource, then the reconciler may generate a new access request to provision access rights to the pending physical resource.
In some circumstances, an access request may require approval before the IAM system provisions the requested access rights. In particular, an access request that is flagged as a potential SoD violation (block 808:Y) may be sent to a reviewer for approval (block 810). If the reviewer confirms the potential SoD violation (block 812:Y), then the access request may be denied (block 814). If, however, the reviewer clears the potential SoD violation, the reviewer may dismiss the SoD violation (block 812:N) and the access request may be further reviewed, e.g., for completeness. It will be appreciated that an access request may be reviewed for completeness even if the access request does not represent a potential SoD violation (block 808:N).
The access request handler may send the access request to a reviewer for a completeness review (block 816). The access request handler may update the status of the corresponding access request event to, e.g., “under review” while the reviewer conducts the review. The IAM system may also provide various interfaces (e.g., web portals or dashboards) that permit a requestor to view the status of submitted access requests and that permit reviewers to review access requests. Moreover, the IAM system may be configured to notify requestors upon changes to the access request status and to notify reviewers of new access requests to review. The IAM system may also notify requestees when new access rights are provisioned. The IAM system may provide these notifications, e.g., via email or via messages in an issue tracking system.
If a reviewer does not approve an access request (block 818:N), then the access request may be denied (block 814). If the reviewer approves the access request (block 818:Y), however, then the IAM system may fulfill the access request by provisioning the requested access rights to the requestee specified in the access request (block 820). In some example implementations, the IAM system may require approval from two reviewers before fulfilling the access request. Accordingly, steps 816-818 may be repeated for a second reviewer. A reviewer may not approve the access request where, for example, the access request is missing information or is otherwise incomplete.
Whether or not an access request is approved (block 818:Y) or denied (block 814), the IAM system updates the status of the access request (block 822). The IAM system may also notify the requestor of the status of the access request (block 824). When an access request is approved, for example, the IAM system may set the status of the access request event to “approved” and notify the requestor of the approval. If the access request is denied, however, the IAM system may set the status of the access request event to “denied” and likewise notify the requestor. When the IAM system denies an access request, the IAM system may indicate the reason for the denial, e.g., the access request may be incomplete or represent an SoD violation. The requestor may thus have the opportunity to revise the access request, e.g., by providing the missing information or specifying a different resource. The requestor may then resubmit the access request for approval and fulfillment.
As seen in
In some situations, an individual may be assigned a new business role and need access to the logical resources associated with that business role. In the physical context, assigning an individual to a business role may be implemented by adding the user account for the individual to the user account group corresponding to the business role. As a concrete example, a newly hired individual to the enterprise may be assigned to a basic employee role associated with basic resources such as email and timekeeping resources. The IAM system may thus provision access rights to the corresponding physical resources associated with the basic employee role (e.g., the email application, the email server, and the timekeeping application). The individual may then be assigned to a specific business role, e.g., an entry-level role. The entry-level role may be associated with various business activities such as opening, maintaining, and closing customer accounts; processing withdrawals and deposits; and other teller-related activities. Accordingly, the IAM system may provision access rights to the physical resources associated with teller role. As the individual is promoted through the organization, the individual may be assigned to additional roles such as senior-level roles and be provisioned with access rights to the physical resources associated with such senior-level roles. It will thus be appreciated that an individual may, in some circumstances, be associated with multiple roles (e.g., an entry-level role as well as a senior-level role) whereby resources and permissions may overlap. Accordingly, access rights may be provisioned based on the respective business activities and business tasks associated with business roles. It will also be appreciated that, in other situations, individual business activities and individual business tasks may be assigned to an individual of an enterprise without changing the business role the individual is assigned to.
If the access request specifies, for example, a business role (block 906:By Business Role), then the access request handler of the IAM system may identify the set of business activities associated with the business role (block 908). For each business activity in the set of business activities, the access request handler may identify the respective sets of business tasks associated with the business activities (block 910). In a similar fashion, the access request handler may identify the set of logical permissions associated with each of the business tasks (block 912). In turn, the access request handler may obtain the physical permission specifications for each of the logical permissions (block 914). In order to obtain the physical permission specifications, the access request handler may first derive the logical entitlements based on the logical permissions as described above. The access request handler may provide the logical entitlements to entitlement translator, which generates the physical entitlement specification based on the logical entitlements and the physical permission specifications as also described above. The entitlement translator may then provide the physical entitlement specifications to the access control manager, which contacts the various resource managers of the physical resources identified in the physical entitlement specifications. The resource managers may thus provision access rights to the physical resources in accordance with the physical entitlement specification (block 916). As noted above, provisioning event records may be created as access rights are provisioned (block 918). In this way, provisioned access rights may be traced back to requested access rights during the reconciliation process.
If the access request alternatively specifies a business activity (block 906:By Business Activity), then steps 910-918 may be performed to provision access rights to the physical resources associated with the business activities. Physical resources associated with business activities may be identified through the relationships of business tasks, logical permissions, and logical resources provided by the IAM data model. If the access request specifies a business task (block 906:By Business Task), then steps 912-918 may be performed to provision access to the physical resources associated with the business tasks. Physical resources may likewise be associated with business tasks through the relationships of logical permissions and logical resources provided by the IAM data model.
As also noted above, an access request may specify a particular logical permission to provision for a requestee (block 906:By Logical Permission). In this circumstance, steps 914-918 may be performed to provision access to the physical resources associated with the logical permission. As noted above, an access request may specify a particular physical permission specification (block 906:By Physical Permission specification). In this other circumstance, steps 916-918 may be performed to provision access rights to the physical resources indicated in the physical permission specification.
Moreover, an access request may specify a resource and a business unit (block 906:By Business Unit). A business unit also be referred to as an organization that includes a collection of individuals. Additionally, an organization may be associated with other organizations thereby allowing for a hierarchical structuring of business units. An enterprise may prefer to have each individual of a business unit have the same logical permissions. Accordingly, the IAM system may provision access rights for each logical permission associated with a business unit when a new individual is assigned to the business unit. The IAM system may also provision access rights for each individual associated with a business unit when a new logical permission is assigned to the business unit. Furthermore, the IAM system may recursively identify logical permissions or individual associated with other organizations of the business unit hierarchy and provision access rights to those related business units.
In
As noted above, a business unit may be associated with another business unit in a hierarchical structure. Accordingly, the IAM system may recursively provision access rights for other business units hierarchically above or below the specified business unit. The access request may specify whether the access request should be recursively applied to related business units. If the access request does not specify recursive provisioning of access rights (block 928:N), then the access request handler may conclude the provisioning process (block 930).
If, however, the access request does specify recursive provisioning of access rights to related business units (block 928:Y), then the access request handler may identify the direction to proceed through the hierarchy (block 932), e.g., up or down from the current business unit as well as the distance from the current business unit, e.g., the number of recursion levels (block 934). The access request may indicate the direction and number of levels for recursively provisioning access rights. Having provisioned access rights for the current business unit, the access request handler may next select a related business unit based on the recursion direction and recursion level (block 936) and provision access rights for the related business unit (block 938) as described above. For example, steps 920-926 may be repeated to provision the access rights for the related business unit. If there are more related business units to provision access rights for, (block 940:Y), then steps 936-938 may be repeated to provision access rights for those additional related business units. Otherwise the access manager may conclude the provision process (block 930) if there are no more business units to provision (block 940:N).
Separation-of-duty violations may be checked at various levels of the business architecture. For example, SoD violations may be checked for business roles, business activities, business tasks, logical permissions, logical entitlements, physical permissions, physical entitlements, and for other IAM-related aspects. In
Accordingly, if the access request specifies a new business role to add to a user (block 1004:By Business Role), the SoD verifier may identify the business activities associated with the new business role (block 1006). The SoD verifier may then compare each business activity of the new business role to the existing business activities associated with the user (block 1008). If the SoD verifier determines that one of the new business activities do not include business tasks that are incompatible with the current business tasks associated with the user, then the SoD verifier may determine a potential SoD violation would not result (block 1010:N). The SoD verifier may therefore verify the access request (block 1012) so that access rights may be provisioned for the user. If, however, the SoD verifier determines that one of the new business activities to add includes a business task that is incompatible with a current business task of the user (1010:Y), then the SoD verifier may flag the access request as a potential SoD violation (block 1014). If the access request specifies a new business activity to add to the user (block 1004:By Business Activity), then the SoD verifier may compare the business tasks of the new business activity to the current business tasks associated with the user (block 1008) as described above. With the benefit of
If the access request specifies a logical permission to add to the user (block 1004:By Logical Permission), then the SoD verifier may carry out similar steps to determine whether an SoD violation would result if the new logical permission were provisioned for the user. As shown by way of example in
As also shown by way of example in
Once access rights have been provisioned for a user account, the reconciler of the IAM system may reconcile the access rights for the user account.
The reconciler may select one of the current physical resources to reconcile (block 1108) and compare the selected current physical resource to the set of physical entitlement specifications associated with the user account (block 1110). The reconciler may, for example, compare the current physical resource to each physical entitlement specification in the set of physical entitlement specifications. If the selected current physical resource is found in at least one of the physical entitlement specifications (block 1112:Y), then the access rights as provisioned for the current physical resource is traceable back to an access request through the related entities of the IAM data model. In particular, the physical entitlement specification that indicates the current physical resource may be traced through the IAM data model to a logical entitlement and thus to an access request. The reconciler may therefore determine that the user account is authorized to access the current physical resource undergoing reconciliation and move on to the next physical entitlement implementation.
If there are additional current physical resources to reconcile for the user account (block 1114:Y), then the reconciler may select the next current physical resource (block 1116) and repeat steps 1110-1112 to reconcile the next selected current physical resource. If there are no additional current physical resources to reconcile for the user account (block 1114:N), then the reconciler may reconcile current physical resources accessible by additional user accounts. If there are additional user accounts to reconcile (block 1118:Y), then the reconciler may select the next user account (block 1120) and repeat steps 1104-1116 to reconcile the current physical resources accessible by the next selected user account. If there are no additional user accounts to reconcile (block 1118:N), however, then the reconciler may conclude the reconciliation process (block 1122).
If the reconciler cannot locate a physical entitlement specification that specifies the current physical resource (block 1112:N), however, then the reconciler may determine that the current physical resource accessible to the user account cannot be traced back to an access request and generate a reconciliation exception (block 1124). In response to the reconciliation exception, the reconciler may notify (e.g., via email) an individual such as a manager that a user has been provisioned access rights to a physical resource that cannot be traced back to an access request. In other example implementations, the reconciler may automatically create an access request to revoke access rights to the current physical resource that cannot be traced back to an access request (block 1126). In this way, the IAM system may advantageously automate various aspects of managing access rights to the physical computing resources of an enterprise.
As seen in
If the business manager cannot locate the selected current logical resource in at least one of the logical entitlements (block 1214:N), then the business manager may determine the individual is not authorized to access the current logical resource and flag the current logical resource as unauthorized (block 1216). In response to determining the current logical resource accessible by the individual not authorized, the business manager may submit an access request to revoke the access rights associated with the current logical resource (block 1218). If, however, the business manager can locate the selected current logical resource in at least one of the logical entitlements (block 1216:Y), then the business manager may determine the individual is authorized to access the current logical resource and move on to the next current logical resource accessible to the individual. If there are additional logical resources to review (block 1220:Y), then the business manager may select the next logical resource accessible to the individual under review (block 1222) and repeat steps 1212-1214 to review the next selected logical resource.
If there are no additional logical resources to review for the individual (block 1220:N), then the business manager may move on to another individual to review. If there are additional individuals remain to review (block 1224:Y), then the business manager may select the next individual (block 1226) and repeat steps 1206-1222 for the next selected individuals. If the business manager has conducted an access review for all of the individuals under review (block 1224:N), then the business manager may conclude the access review (block 1228).
It will be appreciated that access reviews may also be utilized to identify logical resources that are not—but should be—accessible to an individual. A business manager may therefore also submit access requests to provision access rights for any logical resources that should be accessible to the individual. It will also be appreciated that the IAM system may automate various aspects of conducting access reviews including, e.g., obtaining the set of current logical resources and the set of logical entitlements for a user, comparing the current logical resources to the logical entitlements, and submitting access requests to add or remove access rights. Moreover, the IAM system may include a module (e.g., an access review module or access reviewer) to automatically conduct access reviews. In some example implementations, the reconciler may also function as an access reviewer to review and reconcile the logical computing resources a user has access to. The access reviewer (or reconciler) may also determine whether a current logical resource to which the user has access can be traced back to an access request through a logical entitlement as described above. The access review module (or reconciler) may provide a summary of the access review to the business manager.
The access review summary may indicate, e.g., the logical computing resources that have been requested for the user and the logical computing resources to which the user currently has access. The access review summary may be provided as an electronic document which can be printed in hardcopy or, additionally or alternatively, as an electronic display presented at an interface such as a web portal or dashboard. The access review summary may also indicate the current logical resources to which the user has access that cannot be traced back to an access request, in other words, current logical resources that are not indicated in any of the logical entitlements associated with the user. The access request summary may include information about the access request, e.g., the date the access request was submitted, the requestor, the requestee, the date the access request was approved, the individual that approved the access request (an approver), and other types of access request information. The access review summary may also indicate logical resources that were requested for the user but the user cannot access. The user may not be able to access the logical resource if the user has not been provisioned with access rights to one or more of the physical resources associated with the logical resource. A business manager or the access reviewer may thus submit access requests to adjust access to the logical resources based on the access review summary, e.g., to disable access to logical resources the user should not have access to or to enable access to logical resources the user should have access to.
Referring to
In
In
It will be appreciated that the portions 1300-1800 of IAM data models shown in
The disclosures set forth above provide various technological innovations and advantages. First, the systems and methods described above allow business managers to submit access requests in business terms, which are translated into physical terms to provision access rights to physical computing resources. This reduces the possibility that the user account of an individual will be provisioned with access rights to physical computing resources that the individual should not have access to. In addition, the components of the IAM system automate aspects of the provisioning process to add, remove, or change access rights to physical computing resources. Furthermore, the IAM system may automatically reconcile access rights as provisioned and implemented with access rights as requested and specified. If the IAM system determines that a user account has been provisioned with access rights to a physical computing resource it should not have access to, then the IAM system may remedy the unauthorized access by automatically generating and submitting access request to revoke access to the physical computing resource. These and other technological advantages will be appreciated with the benefit of this disclosure.
Aspects of the invention have been described in terms of illustrative embodiments thereof. Numerous other embodiments, modifications and variations within the scope and spirit of the appended claims will occur to persons of ordinary skill in the art from a review of this disclosure. For example, one of ordinary skill in the art will appreciate that the steps illustrated in the illustrative figures may be performed in other than the recited order, and that one or more steps illustrated may be optional in accordance with aspects of the invention.
This application is a continuation of U.S. patent application Ser. No. 13/945,638 entitled “Access Requests at IAM System Implementing IAM Data Model” and filed on Jul. 18, 2013 which is a continuation-in-part of U.S. patent application Ser. No. 13/801,314 entitled “Common Data Model for Identity and Access Management Data” and filed on Mar. 13, 2013 which claims the benefit of U.S. Provisional Pat. App. No. 61/740,205 entitled “Common Data Model for Identity Access Management Data” and filed on Dec. 20, 2012, each of which are incorporated by reference in their entirety herein.
| Number | Name | Date | Kind |
|---|---|---|---|
| 5574927 | Scantlin | Nov 1996 | A |
| 5649099 | Theimer et al. | Jul 1997 | A |
| 5889953 | Thebaut et al. | Mar 1999 | A |
| 5987611 | Freund | Nov 1999 | A |
| 6321334 | Jerger et al. | Nov 2001 | B1 |
| 6400726 | Piret et al. | Jun 2002 | B1 |
| 6434559 | Lundberg et al. | Aug 2002 | B1 |
| 6460141 | Olden | Oct 2002 | B1 |
| 6738973 | Rekimoto | May 2004 | B1 |
| 6748447 | Basani et al. | Jun 2004 | B1 |
| 6782350 | Burnley et al. | Aug 2004 | B1 |
| 6947989 | Gullotta et al. | Sep 2005 | B2 |
| 6968385 | Gilbert | Nov 2005 | B1 |
| 6983278 | Yu et al. | Jan 2006 | B1 |
| 7075895 | Hanam | Jul 2006 | B1 |
| 7260689 | Xu et al. | Aug 2007 | B1 |
| 7614082 | Adams et al. | Nov 2009 | B2 |
| 7630974 | Remahl et al. | Dec 2009 | B2 |
| 7657453 | Guldner et al. | Feb 2010 | B2 |
| 7739245 | Agarwal et al. | Jun 2010 | B1 |
| 7831642 | Kumaresan et al. | Nov 2010 | B1 |
| 7895638 | Becker et al. | Feb 2011 | B2 |
| 8051298 | Burr et al. | Nov 2011 | B1 |
| 8082335 | Mishra et al. | Dec 2011 | B2 |
| 8121913 | Bracken et al. | Feb 2012 | B2 |
| 8135633 | LeBaron et al. | Mar 2012 | B1 |
| 8160904 | Smith | Apr 2012 | B1 |
| 8196195 | Bartley et al. | Jun 2012 | B2 |
| 8204907 | Smith | Jun 2012 | B1 |
| 8230434 | Armstrong et al. | Jul 2012 | B2 |
| 8306854 | Bray et al. | Nov 2012 | B1 |
| 8458337 | Corley et al. | Jun 2013 | B2 |
| 8533168 | Kuehr-McLaren et al. | Sep 2013 | B2 |
| 8539556 | Brandwine | Sep 2013 | B1 |
| 8543607 | Sreedhar | Sep 2013 | B2 |
| 8555403 | Kilday | Oct 2013 | B1 |
| 8613051 | Nguyen | Dec 2013 | B2 |
| 8635689 | Hernandez et al. | Jan 2014 | B2 |
| 8639622 | Moore et al. | Jan 2014 | B1 |
| 8645843 | Chee et al. | Feb 2014 | B2 |
| 8661534 | Chatterjee et al. | Feb 2014 | B2 |
| 8688813 | Maes | Apr 2014 | B2 |
| 8700581 | Paknad et al. | Apr 2014 | B2 |
| 8706692 | Luthra et al. | Apr 2014 | B1 |
| 8775593 | O'Sullivan et al. | Jul 2014 | B2 |
| 8964990 | Baer et al. | Feb 2015 | B1 |
| 9244818 | Paleja | Jan 2016 | B1 |
| 9246945 | Chari et al. | Jan 2016 | B2 |
| 20020095322 | Zarefoss | Jul 2002 | A1 |
| 20020099825 | Fertell et al. | Jul 2002 | A1 |
| 20020156816 | Kantrowitz et al. | Oct 2002 | A1 |
| 20020156904 | Gullotta et al. | Oct 2002 | A1 |
| 20020169876 | Curie | Nov 2002 | A1 |
| 20030005333 | Noguchi et al. | Jan 2003 | A1 |
| 20030061404 | Atwal et al. | Mar 2003 | A1 |
| 20030083846 | Curtin et al. | May 2003 | A1 |
| 20030221012 | Herrmann | Nov 2003 | A1 |
| 20040010463 | Hahn-Carlson et al. | Jan 2004 | A1 |
| 20040034582 | Gilliam et al. | Feb 2004 | A1 |
| 20040158455 | Spivack et al. | Aug 2004 | A1 |
| 20040181771 | Anonsen et al. | Sep 2004 | A1 |
| 20040186798 | Blitch et al. | Sep 2004 | A1 |
| 20040210580 | Butler et al. | Oct 2004 | A1 |
| 20040267552 | Gilliam et al. | Dec 2004 | A1 |
| 20050021360 | Miller et al. | Jan 2005 | A1 |
| 20050027948 | Marlan et al. | Feb 2005 | A1 |
| 20050097353 | Patrick et al. | May 2005 | A1 |
| 20050114226 | Tripp et al. | May 2005 | A1 |
| 20050143231 | Turnbull et al. | Jun 2005 | A1 |
| 20050160411 | Sangal et al. | Jul 2005 | A1 |
| 20050187852 | Hwang | Aug 2005 | A1 |
| 20050227694 | Hayashi | Oct 2005 | A1 |
| 20050262188 | Mamou et al. | Nov 2005 | A1 |
| 20050288978 | Furland et al. | Dec 2005 | A1 |
| 20060005256 | Cox | Jan 2006 | A1 |
| 20060015450 | Guck et al. | Jan 2006 | A1 |
| 20060031679 | Soltis et al. | Feb 2006 | A1 |
| 20060136582 | Mills | Jun 2006 | A1 |
| 20060137019 | Dettinger et al. | Jun 2006 | A1 |
| 20060143685 | Vasishth et al. | Jun 2006 | A1 |
| 20060155738 | Baldwin et al. | Jul 2006 | A1 |
| 20060178898 | Habibi | Aug 2006 | A1 |
| 20060190985 | Vasishth et al. | Aug 2006 | A1 |
| 20060293029 | Jha et al. | Dec 2006 | A1 |
| 20070005601 | Gaucas | Jan 2007 | A1 |
| 20070006284 | Adams et al. | Jan 2007 | A1 |
| 20070022315 | Comegys | Jan 2007 | A1 |
| 20070053381 | Chacko et al. | Mar 2007 | A1 |
| 20070129960 | Farrell | Jun 2007 | A1 |
| 20070156912 | Crawford | Jul 2007 | A1 |
| 20070185814 | Boccon-Gibod et al. | Aug 2007 | A1 |
| 20070214497 | Montgomery et al. | Sep 2007 | A1 |
| 20070233531 | McMahon | Oct 2007 | A1 |
| 20070233600 | McMahon | Oct 2007 | A1 |
| 20070245013 | Saraswathy | Oct 2007 | A1 |
| 20080005321 | Ma et al. | Jan 2008 | A1 |
| 20080040810 | Kurokawa | Feb 2008 | A1 |
| 20080052102 | Taneja et al. | Feb 2008 | A1 |
| 20080060058 | Shea et al. | Mar 2008 | A1 |
| 20080120302 | Thompson et al. | May 2008 | A1 |
| 20080133907 | Parkinson | Jun 2008 | A1 |
| 20080148253 | Badwe et al. | Jun 2008 | A1 |
| 20080215509 | Charlton | Sep 2008 | A1 |
| 20080244602 | Bennington et al. | Oct 2008 | A1 |
| 20080244605 | Bennington et al. | Oct 2008 | A1 |
| 20080256568 | Rowland | Oct 2008 | A1 |
| 20080288330 | Hildebrand et al. | Nov 2008 | A1 |
| 20080306985 | Murray et al. | Dec 2008 | A1 |
| 20080313703 | Flaks et al. | Dec 2008 | A1 |
| 20080320603 | Ito | Dec 2008 | A1 |
| 20090063691 | Kalofonos et al. | Mar 2009 | A1 |
| 20090089291 | Daily et al. | Apr 2009 | A1 |
| 20090132813 | Schibuk | May 2009 | A1 |
| 20090138960 | Felty et al. | May 2009 | A1 |
| 20090150981 | Amies | Jun 2009 | A1 |
| 20090172674 | Bobak et al. | Jul 2009 | A1 |
| 20090287529 | Johnson | Nov 2009 | A1 |
| 20090307597 | Bakman | Dec 2009 | A1 |
| 20090313079 | Wahl | Dec 2009 | A1 |
| 20090320088 | Gill et al. | Dec 2009 | A1 |
| 20100061249 | Rius i Riu et al. | Mar 2010 | A1 |
| 20100077458 | Stout et al. | Mar 2010 | A1 |
| 20100131526 | Sun et al. | May 2010 | A1 |
| 20100161634 | Caceres | Jun 2010 | A1 |
| 20100217639 | Wayne et al. | Aug 2010 | A1 |
| 20100228989 | Neystadt et al. | Sep 2010 | A1 |
| 20100250688 | Sachs et al. | Sep 2010 | A1 |
| 20100250730 | Menzies et al. | Sep 2010 | A1 |
| 20100318446 | Carter | Dec 2010 | A1 |
| 20100319051 | Bafna et al. | Dec 2010 | A1 |
| 20100333167 | Luo et al. | Dec 2010 | A1 |
| 20110004085 | Mensinger et al. | Jan 2011 | A1 |
| 20110072018 | Walls et al. | Mar 2011 | A1 |
| 20110107436 | Cholas et al. | May 2011 | A1 |
| 20110113493 | Moore | May 2011 | A1 |
| 20110128886 | Husney | Jun 2011 | A1 |
| 20110173545 | Meola | Jul 2011 | A1 |
| 20110191213 | Mora et al. | Aug 2011 | A1 |
| 20110239044 | Kumar et al. | Sep 2011 | A1 |
| 20110264278 | Gilbert et al. | Oct 2011 | A1 |
| 20110265150 | Spooner et al. | Oct 2011 | A1 |
| 20110288907 | Harvey et al. | Nov 2011 | A1 |
| 20110302622 | Bregman et al. | Dec 2011 | A1 |
| 20120029969 | Franke et al. | Feb 2012 | A1 |
| 20120030072 | Boudreau et al. | Feb 2012 | A1 |
| 20120030073 | Boudreau et al. | Feb 2012 | A1 |
| 20120042354 | Vitiello | Feb 2012 | A1 |
| 20120079556 | Wahl | Mar 2012 | A1 |
| 20120088540 | Smith et al. | Apr 2012 | A1 |
| 20120095797 | Nishimura et al. | Apr 2012 | A1 |
| 20120098638 | Crawford | Apr 2012 | A1 |
| 20120102489 | Staiman et al. | Apr 2012 | A1 |
| 20120110670 | Mont et al. | May 2012 | A1 |
| 20120134550 | Knoplioch et al. | May 2012 | A1 |
| 20120151512 | Talbert et al. | Jun 2012 | A1 |
| 20120173728 | Haskins et al. | Jul 2012 | A1 |
| 20120185454 | Zhang | Jul 2012 | A1 |
| 20120216243 | Gill et al. | Aug 2012 | A1 |
| 20120221347 | Reiner | Aug 2012 | A1 |
| 20120233312 | Ramakumar et al. | Sep 2012 | A1 |
| 20120240242 | Ferenczi et al. | Sep 2012 | A1 |
| 20120266073 | Tanaka et al. | Oct 2012 | A1 |
| 20120266228 | Dash et al. | Oct 2012 | A1 |
| 20120278708 | Jesudasan et al. | Nov 2012 | A1 |
| 20120278903 | Pugh | Nov 2012 | A1 |
| 20120297456 | Rose et al. | Nov 2012 | A1 |
| 20120317565 | Carrara et al. | Dec 2012 | A1 |
| 20130013548 | Alexander et al. | Jan 2013 | A1 |
| 20130031070 | Ducharme et al. | Jan 2013 | A1 |
| 20130042294 | Colvin et al. | Feb 2013 | A1 |
| 20130046884 | Frost et al. | Feb 2013 | A1 |
| 20130067093 | Moreno et al. | Mar 2013 | A1 |
| 20130067538 | Dharmarajan et al. | Mar 2013 | A1 |
| 20130080520 | Kiukkonen et al. | Mar 2013 | A1 |
| 20130097223 | Mishkevich et al. | Apr 2013 | A1 |
| 20130111489 | Glew et al. | May 2013 | A1 |
| 20130198639 | Casco-Arias Sanchez et al. | Aug 2013 | A1 |
| 20130227638 | Giambiagi et al. | Aug 2013 | A1 |
| 20130246901 | Massand | Sep 2013 | A1 |
| 20130254866 | Koster et al. | Sep 2013 | A1 |
| 20130283356 | Mardikar et al. | Oct 2013 | A1 |
| 20130298202 | Warshavsky et al. | Nov 2013 | A1 |
| 20130312084 | Tandon | Nov 2013 | A1 |
| 20130316746 | Miller et al. | Nov 2013 | A1 |
| 20130326580 | Barclay et al. | Dec 2013 | A1 |
| 20130332984 | Sastry et al. | Dec 2013 | A1 |
| 20130333021 | Sellers et al. | Dec 2013 | A1 |
| 20140075492 | Kapadia et al. | Mar 2014 | A1 |
| 20140101061 | Boudreau et al. | Apr 2014 | A1 |
| 20140108404 | Chen et al. | Apr 2014 | A1 |
| 20140109168 | Ashley et al. | Apr 2014 | A1 |
| 20140143831 | Fieweger | May 2014 | A1 |
| 20140164544 | Gagneraud | Jun 2014 | A1 |
| 20140173035 | Kan et al. | Jun 2014 | A1 |
| 20140181913 | Kling et al. | Jun 2014 | A1 |
| 20140181914 | Kling et al. | Jun 2014 | A1 |
| 20140181965 | Kling et al. | Jun 2014 | A1 |
| 20140196115 | Pelykh | Jul 2014 | A1 |
| 20140207813 | Long et al. | Jul 2014 | A1 |
| 20140208399 | Ponzio, Jr. | Jul 2014 | A1 |
| 20140237498 | Ivins | Aug 2014 | A1 |
| 20140280977 | Martinez et al. | Sep 2014 | A1 |
| 20140282825 | Bitran et al. | Sep 2014 | A1 |
| 20140282880 | Herter et al. | Sep 2014 | A1 |
| 20140282922 | Iwanski et al. | Sep 2014 | A1 |
| 20140289402 | Moloian et al. | Sep 2014 | A1 |
| 20140289796 | Moloian et al. | Sep 2014 | A1 |
| 20140298423 | Moloian et al. | Oct 2014 | A1 |
| 20140331277 | Frascadore et al. | Nov 2014 | A1 |
| 20140337971 | Casassa Mont et al. | Nov 2014 | A1 |
| 20140359085 | Chen | Dec 2014 | A1 |
| 20140359695 | Chari et al. | Dec 2014 | A1 |
| 20140365353 | Shvarts | Dec 2014 | A1 |
| 20140379593 | Koehler et al. | Dec 2014 | A1 |
| 20140380058 | Agarwal et al. | Dec 2014 | A1 |
| 20150026823 | Ramesh et al. | Jan 2015 | A1 |
| 20150066572 | McLaren et al. | Mar 2015 | A1 |
| 20150082432 | Eaton et al. | Mar 2015 | A1 |
| 20150120520 | Prokopenko et al. | Apr 2015 | A1 |
| 20150154418 | Redberg | Jun 2015 | A1 |
| 20150163068 | Cudak et al. | Jun 2015 | A1 |
| 20150281239 | Brophy | Oct 2015 | A1 |
| 20150319760 | Wright et al. | Nov 2015 | A1 |
| 20150372890 | Fan et al. | Dec 2015 | A1 |
| Number | Date | Country |
|---|---|---|
| 0707264 | Apr 1996 | EP |
| Entry |
|---|
| Tuebora Access Nirvana, “Tuebora IAM Service,” Tuebora, Inc., California, 2012. Retrieved from [http://www.tuebora.com/] on Mar. 27, 2014. |
| Tuebora Access Nirvana, “Access Request, Approval and Delivery,” Tuebora, Inc., California, 2012. Retrieved from [http://www.tuebora.com/] on Mar. 27, 2014. |
| Tuebora Access Nirvana, “Access Change Monitoring,” Tuebora, Inc., California, 2012. Retrieved from [http://www.tuebora.com/] on Mar. 27, 2014. |
| Tuebora Access Nirvana, “Access Certification—Recertification,” Tuebora, Inc., California, 2012. Retrieved from [http://www.tuebora.com/] on Mar. 27, 2014. |
| Easter, C., “Method to Report Access Control of LAN Server Resources on a Per User Basis,” IBM Technical Disclosure Bulletin, Apr. 1992, 1 page. |
| An Oracle White Paper, “Integrated Identity Governance,” a Business Overview, 17 pages, Jul. 2012. |
| Number | Date | Country | |
|---|---|---|---|
| 20160036827 A1 | Feb 2016 | US |
| Number | Date | Country | |
|---|---|---|---|
| 61740205 | Dec 2012 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 13945638 | Jul 2013 | US |
| Child | 14879488 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 13801314 | Mar 2013 | US |
| Child | 13945638 | US |
