Aspects of the disclosure provided generally relate to identity and access management and in particular relates to management of identity and access management data using a common data model.
Identity and access management (IAM) refers to the processes, technologies, and policies for managing digital identities and controlling how identities can be used to access resources. Resources may refer to computer systems including the hardware and software components that make up the computer systems or a network of computer systems. For example, resources may include information systems, applications, services, programs, computing devices (e.g. servers, PCs), network devices (e.g. switches and routers, networks, files, file systems, databases and database objects (e.g. tables, views, and stored procedures), and the like.
Organizations may utilize various IAM products and services to implement IAM processes, which include authentication, access, and auditing. Authentication refers to verifying identities based on one or more credentials in order to gain access to a resource; access refers to managing login accounts, providing access rights to resources, and authorizing the use of resources; and auditing refers to validating and testing authentication and access capabilities.
IAM products and services may maintain event logs that include information about events that occurred during the authentication, access, and auditing processes. Event information may include, for example, the date and time of the event, the resource at which the event occurred, and other information that identifies and categorizes the event. In this regard, the event log data generated by IAM technologies and services may be referred to as IAM data.
Organizations are increasingly interested in performing large scale data analysis on the IAM data generated by IAM products and services. Analysis of IAM data can be useful, for example, to demonstrate compliance with regulatory requirements. Analysis of IAM data can also be useful to preemptively identify threats to the resources of the organization, e.g., from malware operating with the computing systems of the organization. More generally, analysis of IAM data may enable an organization to improve the efficiency and effectiveness of its IAM policies and procedures.
IAM products and services, however, may generate and store IAM data in unique or proprietary formats. IAM data stored in unique or proprietary formats may not be compatible with the formats required by various data analysis tools. To utilize the analytical tools to perform data analysis on the IAM data, a point-to-point mapping between the unique IAM data format and the format required by the data analysis tool may be necessary. Accordingly, organizations may not be able to integrate uniquely formatted IAM data for large scale data analysis of the integrated IAM data at a data analysis tool.
Therefore a need exists for a common data model for IAM data in the IAM domain.
The following presents a simplified summary in order to provide a basic understanding of some aspects of the disclosure. The summary is not an extensive overview of all aspects of the disclosure. It is neither intended to identify key or critical elements nor to delineate the scope of the claims. The following summary merely presents some concepts of the disclosure in a simplified form as a prelude to the description below.
A system for managing identity and access management (IAM) data is provided. An IAM data model may model at least a portion of an IAM domain space and provide a common IAM data format. A mapping module may be configured to transform heterogeneous IAM data provided by a plurality of IAM data sources into homogeneous IAM data formatted according to the common IAM data format. A data store may implement the IAM data model such that the data store is configured to store the homogeneous IAM data.
A computer-implemented method for managing IAM data is also provided. An IAM data model may be implemented at a data store. The IAM data model may model a portion of the IAM domain space and provide a common IAM data format. Heterogeneous IAM data may be received from a plurality of IAM data sources, and the heterogeneous IAM data may be mapped based on the IAM data in order to obtain homogeneous IAM data formatted according to the common IAM data format. The homogeneous IAM data may be stored at a data store in accordance with the IAM data model.
A data model for managing IAM data implemented at an electronic database is also provided. The IAM data model may include a set of logical resource elements that model logical resources of an enterprise, a set of physical resource elements that model physical resources of the enterprise, and a set of access requests elements that model access requests received at an access request manager of the enterprise. The physical resource elements may be respectively associated with the logical resource elements such that access rights for the physical resources may be obtained based on a logical resource specified in the access request.
The details of these and other embodiments of the disclosure are set forth in the accompanying drawings and description below. Other features and advantages of aspects of the disclosure will be apparent from the description and drawings.
Aspects of the disclosure are illustrated by way of example and are not limited by the accompanying figures in which like reference numerals indicate similar elements and in which:
Aspects of the disclosure related to identity and access management (IAM). Identity and access management may alternatively be referred to as identity management (IdM) as well as access and identity management (AIM). As noted above, a common data model for the identity and access management domain is needed. The common IAM data model described below provides a mapping for IAM elements and the relationships between those IAM elements such that uniquely formatted IAM data originating at different sources may be integrated and subsequently analyzed. The IAM data may include identity data compiled during the authentication process, access data compiled during the access process, and event data for events occurring during other IAM processes.
An IAM data source may be any resource utilized to implement IAM processes, policies, or procedures. Examples of IAM data sources that implement IAM processes, policies, or procedures include, for example, a Resource Access Control Facility, an Active Directory service, and a Security Intelligence and Risk Management (SIRM) platform. Each of these IAM technologies may generate and compile IAM data in a unique or proprietary format.
Because these technologies are each utilized to implement IAM processes, however, the IAM data generated by these technologies are semantically related or semantically equivalent within the IAM domain. The common data model provided maps this semantically related data to a common IAM data format such that IAM data across IAM technologies may be subsequently integrated and analyzed.
Referring to
Multiple IAM data sources 104, 106, 108 may generate uniquely formatted IAM data 110, 112, 114 during an IAM process. Data mapping modules 116, 118, 120 may be configured to transform the uniquely formatted IAM data 110, 112, 114 into commonly formatted IAM data 122, 124, 126 that conforms to the common IAM data model 102. As seen in
As shown by way of example, data mapping module 116 may be configured to transform uniquely formatted IAM data 110 into commonly formatted IAM data 122; data mapping module 118 may be configured to transform uniquely formatted data 112 into commonly formatted IAM data 124; and data mapping module 120 may be configured to transform uniquely formatted IAM data 114 into commonly formatted IAM data 126.
Having transformed the uniquely formatted IAM data 112, 114, 116 into commonly formatted IAM data 122, 124, 126, the data store 103 may store the commonly formatted IAM data. The IAM data processing system 100 may integrate the commonly formatted IAM data stored at the data store 103 to obtain integrated IAM data 128. Analytical tools may thus perform data analysis on the integrated IAM data 128 collectively rather than on the uniquely formatted IAM data 110, 112, 114 individually. In this way, the analytical tools may perform large scale data analysis on IAM data originating from multiple IAM data sources.
The IAM data processing system 100 thus avoids having to convert the uniquely formatted IAM data 110, 112, 114 from each IAM data source 104, 106, 108 in a point-to-point fashion. Instead, a single data mapping module 130 may transform the integrated IAM data 128 into IAM data 132 having a format required by an analytical tool 134. Various analytical tools may be selectively employed to analyze the integrated IAM data 128, e.g., using business analytics and business intelligence software.
The system 100 may also be employed to manage access to physical resources 136 and logical resources 138 of an enterprise (e.g., a corporation). Accordingly, the system may also include an access request manager 140 for receiving and processing access requests. The IAM data model 102 may model and create associations between the logical resources 138 and the physical resources 136. The access request manager 140 may initiate provisioning of access rights to logical resources 138 and physical resources 136 in response to receipt of an access request. Further, the access request manager may provision access rights and entitlements based on a physical permission specification 142. Access requests will be discussed in further detail below.
I/O 209 may include a microphone, keypad, touch screen, and/or stylus through which a user of the enhanced backup and retention management module 201 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 215 and/or storage to provide instructions to processor 203 for enabling device 201 to perform various functions. For example, memory 215 may store software used by the device 201, such as an operating system 217, application programs 219, and an associated database 221. Processor 203 and its associated components may allow the device 201 to run a series of computer-readable instructions to process IAM data. For instance, processor 203 may cause module 201 to extract IAM data from an IAM data source and transform the IAM data to the common IAM data format such that the IAM data conforms to the common IAM data model. In addition, processor 203 may retrieve the commonly formatted IAM data from the database 221 and transform the commonly formatted IAM data based on a format required by an analytical tool.
The server 201 may operate in a networked environment supporting connections to one or more remote computers, such as terminals 241 and 251. The terminals 241 and 251 may be personal computers or servers that include many or all of the elements described above relative to the computing device 201. The network connections depicted in
Additionally, an application program 219 used by the IAM data processing module 201 according to an illustrative embodiment of the disclosure may include computer executable instructions for invoking functionality related to extracting IAM data from IAM sources and mapping the extracted IAM data to the common IAM data model.
IAM data processing module 201 and/or terminals 241 or 251 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 computing system environments or configurations. Examples of well-known computing 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
IAM data may be retrieved from an IAM data source (step 304). Various tools may be selectively employed to extract the IAM data from the IAM data sources, e.g., data integration software. A data mapping module may map the uniquely formatted IAM data to the common IAM data model (step 306). Multiple data mapping modules may be employed to respectively map IAM data extracted from multiple IAM data sources. In this way, uniquely formatted IAM data from multiple sources is transformed to a common IAM data format, e.g., the common IAM data format defined by the common IAM data model described in this disclosure.
Having mapped the extracted IAM data to the common IAM data format, the commonly formatted IAM data may be stored in the data store that implements the common IAM data model (step 308). If additional IAM data sources remain (step 310), then steps 304-308 may be repeated to retrieve uniquely formatted IAM data from another IAM data source, map the uniquely formatted IAM data to the common IAM data model, and store the transformed commonly formatted IAM data in the data store that implements the common IAM data model.
The common IAM data model thus permits the combination and integration of IAM data from different IAM data sources. Once the commonly formatted IAM data has been stored in the data storage device, the IAM data is available for subsequent processing as needed, e.g., for large scale data analysis.
To perform data analysis, commonly formatted IAM data may be retrieved from the data storage device (step 312). The commonly formatted IAM data retrieved from the data store may be IAM data integrated from multiple IAM data sources. A data mapping module may transform the commonly formatted IAM data to a format required by an analytical tool (step 314). The analytical tool may thus perform data analysis on the integrated IAM data that originated from multiple IAM data sources as uniquely formatted IAM data (step 316).
An enterprise (e.g., a business) may also utilize the common IAM data model to manage access rights to various resources of the business.
Profiles and roles associated with the enterprise may be identified and modeled using the IAM data model implemented at the data store (block 408), e.g., by adding and updating database records corresponding to and associated with the profile and roles. Business tasks, activities, processes, and functions may be identified and also modeled using the IAM data model implemented at the data store (block 410), e.g., database records corresponding to the business tasks, activities, processes, and functions may be created, updated, and related at the database implementing the IAM data model. For example, business tasks may be associated with business activities using the IAM data model implemented at the data store (block 412). Additionally, business processes may be associated with business activities using the IAM data model implemented at the data store (block 414). Further, business functions may be associated with business processes using the IAM data model implemented at the data store (block 416). Moreover, business activities may be associated with logical permissions using the IAM data model implemented at the data store (block 418). Job functions may be identified and modeled using the IAM data model implemented at the data store (block 420), e.g., by adding and updating database records corresponding to and associated with the job functions. Job functions may be associated with business activities using the IAM data model implemented at the data store (block 422). Business managers may, for example, be responsible for identifying and modeling profiles and roles as well as the business tasks, activities, processes, and functions of the enterprise.
Having identified, modeled, and associated resources, job functions, and business tasks, activities, processes, and functions, access to those resources may be provisioned based on a particular job function or business task, activity, process, or function. Accordingly, an access request manager may receive an access request regarding a logical resource (block 424). The access request manager may identify the logical resource indicated in the access request (block 426) and identify one or more physical resources that correspond to the logical resource (block 428). The access request manager may thus initiate provisioning of physical entitlements to the physical resources corresponding to the logical resource (block 430) and obtain physical permissions to those physical resources (block 432). Obtaining the physical permissions may include translating logical permissions into physical permissions based on a physical permission specification associated with the logical resource (block 434). Once the access information has been provisioned, the access request manager may provide the access information for the logical resource to a user (block 436). Access requests will be discussed in further detail below.
In
Referring now to
A user may be anything identified on a system or a network. Users may include, for example, associates and customers that access bank systems. A resource manager may issue user accounts to users in order to manage access to the resources associated with the resource manager. One example of a user account may be a server login account that provides access to a server. The user account, in this example, may or may not provide access to other resources associated with the server such as files stored at the server. A resource manager may assign an access identifier to a user account, e.g., an identifier for a directory service.
Access refers to the ability of a user to perform an action on a resource. Examples of access rights include, for example, create, read, update, delete, and execute. An access right refers to the authority to perform types of access such as reading or writing to a file. Entities may include, for example, individuals, organizations, and even other resources. Individuals and organizations may be collectively referred to as parties (e.g., parties to a contract).
A system identifier refers to an identifier for an individual or for a resource in a computing environment. An identifier for a resource may be referred to as a service ID. An Individual as well as a service ID may be associated with a system identifier that may be related to many user accounts. A user account may allow the associated the individual or service ID to access one or more of the resources controlled by a resource manager. In some implementations, a resource may be controlled by multiple resource managers. When an individual or service ID needs to access resources controlled by multiple resource managers, an individual or service ID may be associated with multiple user accounts. User accounts may include a single sign-on account that manages the login process on behalf of other accounts. A single sign on manager is a type of resource manager.
A group may be a container for multiple user accounts and for other groups. A group may, for example, be associated with both user accounts and other groups. A group may also be assigned an access ID. Identifiers for user and groups may share a common set of access IDs. A group may be composed entirely of other groups or of both user accounts and groups. Groups may be nested for any number of levels. Related groups may contain the groups and user accounts that are members of each group.
A physical permission may be a set of one or more access rights to resources. Physical permissions may include, for example, the authority to execute server transactions; authority to read a file, authority to update a database table, and the like. A physical entitlement with respect to an access control list (ACL) may be a combination of a physical permission and a user account (or group). In this way, entitlements may be associated with user account or a group as well as with groups nested within groups. A physical entitlement may serve as the basis for run-time authorization decisions. A profile may be the named collection of permissions, e.g., physical permissions. Rule profiles may be based on job codes or job categories. A physical entitlement with respect to role based access control (RBAC) may be a set of user accounts (or groups) associated with a profile. A physical entitlement based on RBAC may be a set of one or more user accounts (or groups) associated with a profile.
In
A permission may be a set of one or more access rights to one or more logical or physical resources. Permissions may include, for example, access rights to use a particular screen (i.e., a logical resource), access rights to execute a particular application, access rights to delete a row in a database table, and the like. A logical permission may be a set of one or more access rights to one or more logical resources. Logical permissions may include, for example, the ability to access and use customer maintenance screens in order to maintain customer accounts. The IAM data model, in this example, establishes the Logical Permission element as a subtype of Permission. The Logical Permission element may identify a particular logical permission. A logical permission may be associated with multiple combinations of access rights to logical resources. The Logical Permission To Access Rights And Logical Resources element, in this example, associates pairings of access rights and logical resource to a particular logical permission. The IAM data model, in this example, also establishes the Physical Permission element as a subtype of Permission. The Physical Permission To Access Rights And Resources element, in this example, relates a physical permission to combinations of access rights and resources that are deployed on target platforms and used for access decisions at run-time.
A logical permission may be translated into a physical permission that can be deployed to a target platform. A physical permission specification may employed to translate a logical permission to zero, one, or multiple physical permissions. One example includes mapping server transaction codes utilized to execute a set of customer maintenance screens that are defined as logical resources. A logical resource may be associated with a corresponding physical permission specification. A physical permission specification may be associated with pairs of access rights and resources. In this way, logical resources may appear to be seamlessly integrated to a user but involve relationships between multiple physical resources on multiple platforms. The IAM data model, in this example, also establishes the Physical Permission Specification element as a subtype of Permission. The Physical Permission Specification To Access Rights And Resources element relates a specification to specific combinations of access rights and resources.
In
An individual performing a business activity may need access to one or more logical resources (e.g. screens and reports). The Business Activity To Logical Permission element may associate business activities to logical permissions (i.e. access rights to logical resources). A logical resource may be utilized by multiple business activities (e.g. an account lookup screen), and a business activity may utilize multiple logical resources (e.g. screen to request a credit report and a screen to update the customer records). A physical permission may be related to a group, in this example, via the Physical Entitlement-ACL element. A group of physical entitlements may thus be associated with a business activity, in this example, via the Business Activity To Group element.
A job function may be a collection of related business activities. An individual may be associated with a job function. One example of a job function includes a teller at a bank where the teller may perform multiple business activities such as, e.g., opening and servicing customer accounts, taking deposits, processing loan forms, and the like. Business activities may be associated with different business processes. Other examples of business processes include customer relationship management, check processing from deposit through clearing, loan origination to close. A job function may involve performing activities with within each of these business processes.
Roles may be associated with a set of entitlements, e.g., in role based access control (RBAC). The IAM data model, in this example, may associate roles with a set of entitlements that are, in turn, associated with a set of business activities. Logical permissions may be associated with a set of business activities that are, in turn, associated with a job function. The IAM data model, in this example, associates an individual with a job function, job functions with a business activities, and business activities with logical entitlements. The IAM data model, in this example, also associates an individual with a system identifier and through the system identifier to a user account. A user account may be associated with physical entitlements, which may correspond to the implementation of logical entitlements. The IAM data model, in this example, also models incompatible business activities. Incompatible business activities may be business activities where it is undesirable to have the same individual perform those business activities. For example, it may be undesirable to have an individual responsible for originating loans should to approve loans.
The Access Request Detail element may permit a single access request to support many different actions on many different types of requests. The IAM data model, in this example, models five types of access requests, although it will be appreciated that additional or alternative types of access requests may be employed. Access request types may include, e.g., an access request by job function, an access request by business activity, an access request by business unit, an access request by logical permission, and an access request by physical permission specification. An access request detail may be associated with an access request detail action. The Access Request Detail Action Type element may contains a set of actions associated with an access request (e.g. add, suspend, and revoke).
Access request details may be associated with one or more events that include approvals and physical completion of items. The Access Request Detail Event Type element may include the domain of valid event types. The Access Request Detail Item Event History element may include the date time history of respective events.
Job functions may be a collection of specific business activities. An individual may be assigned multiple job functions, and a job function may be associated with particular business activities. For example, a baseline job function may be set up for basic resources such as an email application and a timekeeping application. A business may assign this baseline job function to a new hire and submit an access request for these basic applications. A manager may submit subsequent access requests for other job functions based on activities performed by the new hire. For example, basic teller job function may include business activities for customer service, deposit process, safe deposit boxes, and the like. A senior teller job function may include business activities beyond the scope of responsibility for a basic teller. In this example, a senior teller may be associated with multiple job functions: the baseline job function for access to basic resources, the basic teller job function for access to resources utilized by basic tellers, and the senior teller for access to resources utilized by senior tellers.
In this way, the IAM data model advantageously streamlines the process of identifying logical resources and what job functions, business activities and the like should have access to those resources. Moreover, the IAM data model permits enterprise from dividing the process providing access into a business side and a physical side. On the business side, entitlements may be requested in business terms, and access reviews may be conducted in business terms. On the physical side, the IAM data model establishes a link between access requests in business language and the specifications to provision physical entitlements. Furthermore, a reconciliation process between the physical entitlement specifications and the entitlements provisioned may ensure that provisioned entitlements can be linked to corresponding access requests. As a result, the business may advantageously operate in business terms without regard to the entitlements ultimately provisioned in physical terms. Additionally, access reviews may be performed in the same language as access requests, that is, in terms of job functions, business activities, and logical permissions. Access requests may be provisioned as physical entitlements, and a reconciliation process may allow access reviews to be performed in business terms without referring to the underlying physical entitlements.
An access request (Access Request) may be generated using the user account associated with the individual (Person→System Identifier→User Account) and a job function. The access request may be associated with a the Access Request element and one of the elements corresponding to a subtype of access request, e.g., the Access Request by Job Function element. Access request subtypes may include other attributes specific to each subtype of access request.
Business level access reviews may thus be conducted in terms of the logical permissions associated with an employee via the job function associated with the employee and the business activities associated with the job function. A manager may thus request logical permissions and perform reviews of approved access requests and associated logical entitlements.
Those skilled in the art will appreciate, with the benefit of the approach set forth above with respect to access requests by job function, that similar approaches may be employed with respect to access requests by business activity, access requests by business unit, access requests to particular logical resources, and access requests to particular physical resources. The example IAM data model set forth in
As discussed above, the IAM data model includes sets of elements that model various aspects of the IAM domain. A set of elements that model an aspect of the IAM domain as used in this description refers to one or more elements that model the aspect of the IAM domain. The data model shown in the subsections throughout
In
In
In
In
In
In
In
In
In
In
In
In
In
In
In
Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.
This application claims priority to Provisional Patent App. No. 61/740,205 filed on Dec. 20, 2012 and entitled “COMMON DATA MODEL FOR IDENTITY ACCESS MANAGEMENT DATA,” which is incorporated in its entirety in the present disclosure.
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 |
6711687 | Sekiguchi | Mar 2004 | 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 |
7996368 | Nalder et al. | Aug 2011 | B1 |
8051298 | Burr et al. | Nov 2011 | B1 |
8082335 | Mishra et al. | Dec 2011 | B2 |
8086635 | Rinker | Dec 2011 | B1 |
8121913 | Bracken et al. | Feb 2012 | B2 |
8135633 | LeBaron et al. | Mar 2012 | B1 |
8160904 | Smith | Apr 2012 | B1 |
8181016 | Borgia et al. | May 2012 | B1 |
8204907 | Smith | Jun 2012 | B1 |
8306854 | Bray et al. | Nov 2012 | B1 |
8386711 | Miyamoto et al. | Feb 2013 | B2 |
8438611 | Faitelson et al. | May 2013 | B2 |
8539556 | Brandwine | Sep 2013 | B1 |
8555403 | Kilday | Oct 2013 | B1 |
8613051 | Nguyen | Dec 2013 | B2 |
8639622 | Moore et al. | Jan 2014 | B1 |
8639625 | Ginter et al. | Jan 2014 | B1 |
8661534 | Chatterjee et al. | Feb 2014 | B2 |
8688813 | Maes | Apr 2014 | B2 |
8745711 | Matsuda | Jun 2014 | B2 |
8775593 | O'Sullivan et al. | Jul 2014 | B2 |
8819492 | Dande et al. | Aug 2014 | B2 |
8832410 | Springberg | Sep 2014 | B2 |
8925028 | Talbert et al. | Dec 2014 | B2 |
8964990 | Baer et al. | Feb 2015 | B1 |
9244818 | Paleja | Jan 2016 | B1 |
9246945 | Chari et al. | Jan 2016 | B2 |
9330134 | Long et al. | May 2016 | B2 |
20020013855 | Ishii et al. | Jan 2002 | A1 |
20020095322 | Zarefoss | Jul 2002 | A1 |
20020099825 | Fertell et al. | Jul 2002 | A1 |
20020147801 | Gullotta et al. | Oct 2002 | A1 |
20020156816 | Kantrowitz et al. | Oct 2002 | A1 |
20020156904 | Gullotta et al. | Oct 2002 | A1 |
20020169876 | Curie et al. | 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 |
20040160304 | Mosgrove 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 | 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 |
20060098790 | Mendonca et al. | May 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 |
20060161307 | Patel 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 et al. | Oct 2007 | A1 |
20080005321 | Ma et al. | Jan 2008 | A1 |
20080040810 | Kurokawa | Feb 2008 | A1 |
20080052102 | Taneja | Feb 2008 | A1 |
20080060058 | Shea et al. | Mar 2008 | A1 |
20080098484 | Cicchitto et al. | Apr 2008 | A1 |
20080098485 | Chiou | Apr 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 |
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 |
20100030777 | Panwar et al. | Feb 2010 | A1 |
20100061249 | Riu et al. | Mar 2010 | A1 |
20100067390 | Pereira Valente et al. | Mar 2010 | A1 |
20100077458 | Stout et al. | Mar 2010 | A1 |
20100131526 | Sun et al. | May 2010 | A1 |
20100145771 | Fligler et al. | Jun 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 |
20110061111 | Faitelson et al. | Mar 2011 | A1 |
20110072018 | Walls et al. | Mar 2011 | A1 |
20110078306 | Krishnamurthy | 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 |
20110258683 | Cicchitto | Oct 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 |
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 |
20120311672 | Connor et al. | Dec 2012 | A1 |
20120311684 | Paulsen et al. | Dec 2012 | A1 |
20120317565 | Carrara et al. | Dec 2012 | A1 |
20130013548 | Alexander et al. | Jan 2013 | A1 |
20130030937 | Larguia 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 |
20130047247 | Matsuda | Feb 2013 | A1 |
20130067093 | Moreno 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 |
20130246901 | Massand | Sep 2013 | A1 |
20130316746 | Miller et al. | Nov 2013 | A1 |
20130326580 | Barclay et al. | Dec 2013 | A1 |
20130333021 | Sellers et al. | Dec 2013 | A1 |
20140089511 | McLean | Mar 2014 | A1 |
20140101061 | Boudreau et al. | Apr 2014 | A1 |
20140108251 | Anderson et al. | Apr 2014 | A1 |
20140108404 | Chen et al. | Apr 2014 | A1 |
20140129511 | Bramel et al. | May 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 |
20140244569 | Seto | 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 |
20150249852 | Tang et al. | Sep 2015 | A1 |
20150249864 | Tang et al. | Sep 2015 | A1 |
20150281239 | Brophy | Oct 2015 | A1 |
20150319760 | Wright et al. | Nov 2015 | A1 |
20150372890 | Fan et al. | Dec 2015 | A1 |
20160314578 | Banerjee et al. | Oct 2016 | A1 |
20170060930 | Elkherj et al. | Mar 2017 | A1 |
Number | Date | Country |
---|---|---|
0707264 | Apr 1996 | EP |
2003186708 | Jul 2003 | JP |
Entry |
---|
Access Requests at IAM System Implementing IAM Data Model, U.S. Appl. No. 13/945,638, filed Jul. 18, 2013. |
Verifying Separation-of-Duties at IAM System Implementing IAM Data Model, U.S. Appl. No. 13/945,669, filed Jul. 18, 2013. |
Access Reviews at IAM System Implementing IAM Data Model, U.S. Appl. No. 13/945,656, filed Jul. 18, 2013. |
Reconciling Access Rights at IAM System Implementing IAM Data Model, U.S. Appl. No. 13/945,679, filed Jul. 18, 2013. |
Facilitating Review of Access Rights in a Computing System, U.S. Appl. No. 14/267,571, filed May 1, 2014. |
Reconciliation of Access Rights in a Computing System, U.S. Appl. No. 14/267,578, filed May 1, 2014. |
Computing Resource Inventory System, U.S. Appl. No. 14/267,586, filed May 1, 2014. |
Facilitating Separation-of-Duties when Provisioning Access Rights in a Computing System, U.S. Appl. No. 14/267,584, filed May 1, 2014. |
Granular Risk Expression, U.S. Appl. No. 14/267,590, filed May 1, 2014. |
Quality Assurance Checks of Access Rights in a Computing System, U.S. Appl. No. 14/267,564, filed May 1, 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 | |
---|---|---|---|
20140181003 A1 | Jun 2014 | US |
Number | Date | Country | |
---|---|---|---|
61740205 | Dec 2012 | US |