The Identity Governance catalog is the repository of all collected data. The catalog reflects the current state of the operations database. It includes information about the following entities:
Identities
Identities, also referred to as Users, represent the people who are at the core of the processes within Identity Governance. They are the who in the review process of “who has access to what.” Identities also represent the people who manage and perform the reviews, or who serve as the administrators of Identity Governance.
Identities are the first part of the catalog. Identity Governance can collect, correlate, and publish the identities. Plus, if you integrate with Identity Manager, you can leverage all the capabilities of Identity Manager to provide a synchronized, composite view of the people or things in your organization from multiple changing systems of record. Identity Governance can collect identities from multiple sources but it logically publishes the identities to a single name space in the catalog.
Identity Governance maps the identity and entitlement data to a minimum standard schema. The schema can be extended to include custom attributes to match the shape of your identity and entitlement data.
Groups
Groups, also referred to as User Groups or Identity Groups, are comprised of collected identities and are a useful entity for assigning administrative roles or reviews to a set of people without incurring the administrative overhead of direct assignment.
Applications
Applications in Identity Governance are the source of information about accounts and permissions. Identity Governance provides application definition templates to collect applications.Also, the Identity Manager Advanced Edition Permission collector gathers entitlement-enabled Identity Manager driver objects as applications.
Applications have their own namespaces. Identity Governance can collect and publish the application data (accounts and permissions) per application in parallel. Identity Governance uses the latest published identities in the catalog to map who has what access to permissions in each application when it is published.
Accounts
Accounts generally represent entities that provide access to applications. If you log in to Netflix, you are using an account. If you log in to Gmail, you are using an account. Accounts are not identities. They are the representation of system, application, or data source accessed by an identity. Accounts often specify the type of permissions granted to a user.
In some scenarios, such as system or administrative accounts which are not linked to identities custodians are assigned. You can collect this data directly from the application source, then map and join it to identities while configuring the account collector. If you cannot collect the data, Identity Governance allows you to edit the account and assign one or more custodians from the identities available in the catalog.
Permissions
Permissions, from an Identity Governance perspective, have multiple facets. Permissions can describe any of the following:
Actions that you can take within an application
For example, finance department employees have access to the SAP Finance application (accounts). One employee has the rights granted to run Accounts Payable functions; another employee has the rights granted to run the Accounts Receivable functions. Both have accounts, but different permissions within the same application. This is a case where the Permissions (Accounts Receivable, Accounts Payable) are granted to the application user (account).
Items that you possess to access things
For example, all employees have an electronic badge that allows them access to their office building. These employees do not have an account on the Building Access application to which they must log in, They simply have the access granted to their person via the badge. This is a case where the Permission (badge) is granted directly to the Identity (person).
Permissions can be inherited in the case of hierarchical relationships. For example, for parent-child hierarchy permissions, when a user has an assignment for a child permission, they may also optionally be given an assignment for the parent permission. In such scenarios, the Assignment Type becomes INHERITED for the parent permission. Note that the Assignment Type can be INHERITED as well as DIRECT for the parent permission if the option Nested members in membership query is configured in eDirectory. For more information see, Nested Group in the NetIQ eDirectory Administration Guide.
You can view details of all permission assignments in the Identity Governance Catalog by clicking the Assignment details link on the Accounts and Permissions tab. The assignment details indicate how it was assigned, such as direct or inherited, if the assignment can be revoked or not, the assignment start and end time, or the assignment value.
Roles (Technical Roles)
Technical roles allow business owners to simplify the review process by grouping permissions, and reduces the number of items for business leaders to review. For example, a role called Sales Employee might have permissions associated with sales software applications and financial data and one or more permissions that apply to all employees, such as Garage Access, Building Access, and Read Access to Company Intranet.
Technical roles can be detected if the user has all the permissions defined by the role. Technical roles can also be directly assigned to users and groups. Identity Governance does not collect technical roles.
NOTE:Technical roles can be authorized by business roles. Business roles are higher-level roles focused around common access requirements for business role members. For example, a manager in the Sales Department might need all the permissions associated with a Sales Employee technical role, and need access to the management resources. Identity Governance provides details of business role associated with identities, applications, permissions, and technical roles as separate tabs in the catalog view.