Adding Security Attributes
This section explains about security attributes, the process of uploading security attributes, and mapping security attributes to users in the BD application.
This section covers the following topics:
- About Security Attributes
- Loading Security Attributes
About Security Attributes
Security Attributes help an organization classify their users based on their geography, jurisdiction, and business domain, in order to restrict access to the data that they can view. You need to map the roles with access privileges, and since these roles are associated with user groups, the users associated with the user groups can perform activities throughout various functional areas in the BD application.
The following sections describe the security attributes:
- Jurisdiction: OFSFCCM solutions use Jurisdictions to
limit user access to data in the database. Records from the Oracle client that
the Ingestion Manager loads must be identified with a jurisdiction and users of
the system must be associated with one or more jurisdictions. In the Alert
Viewer system, users can view only data or alerts associated with jurisdictions
to which they have access. You can use a jurisdiction to divide data in the
database. For example:
- Geographical: Division of data based on geographical boundaries, such as countries, states, and so on.
- Organizational: Division of data based on different legal entities that compose the client’s business.
- Other: Combination of geographic and organizational definitions. In addition, it is client driven and can be customized.
Note:
BD application supports up to 1000 jurisdictions. - Business Domain: Business domains are used for data
access controls similar to jurisdiction but have a different objective. The
business domain can be used to identify records of different business types such
as Private Client verses Retail customer, or to provide more granular
restrictions to data such as employee data. The list of business domains in the
system resides in the KDD_BUS_DMN table. The system tags each data record
provided through the Ingestion Manager to one or more business domains. It also
associates users with one or more business domains in a similar fashion. If a
user has access to any of the business domains that are on a business record,
the user can view that record. The business domain field for users and data
records is a multi-value field. For example, you define two business domains:
Private Client and Retail Banking.
A record for an account that is considered both has BUS_DMN_SET=ab. If a user can view business domain a or b, the user can view the record. You can use this concept to protect special classes of data, such as data about executives of the firm. For example, you can define a business domain as e: Executives. You can assign this business domain to the employee, account and customer records that belong to executives. Thus, only specific users of the system have access to these records. If the executive’s account is identified in the Private Client business domain as well, any user who can view Private Client data can view the executive’s record. Hence, it is important not to apply too many domains to one record.
The system also stores business domains in the KDD_CENTRICITY table to control access to Research against different types of entities. Derived External Entities and Addresses inherit the business domain set that is configured in KDD_CENTRICITY for those focus types.
- Scenario Group: Scenario groups are used for data access controls. A scenario group refers to a group of scenarios in the BD applications that identify a set of scenario permissions and to which a user has access rights. The list of scenario groups in the system resides in the KDD_SCNRO_GRP table.
- Organization: Organizations are used for data access controls. Organizations are user group to which a user belongs. The list of Organizations in the system resides in the KDD_ORG table.
Loading Security Attributes
This section covers the following topics: