Security Settings - Teradata Schema Workbench

Teradata Schema Workbench User Guide

Product
Teradata Schema Workbench
Release Number
16.20
16.10
15.10
Published
June 2015
Language
English (United States)
Last Update
2018-05-25
dita:mapPath
gvf1512702977003.ditamap
dita:ditavalPath
Audience_PDF_include.ditaval
dita:id
B035-4106
Product Category
Teradata Tools and Utilities

Teradata BI Repository implements security using standard Teradata Database security roles.

Teradata BI Repository requires the TBI_SERVICE, TBI_WORKBENCH, and TBI_USER roles to be defined by the DBA using normal database tools and assigned to users. See Mandatory Security Roles.

All BI client users and Teradata OLAP Connector users require access to the TBI_USER role. However, this role only allows the user to start up Teradata OLAP Connector. Access to individual cube schemas and cubes requires additional configuration.

Additionally, you will need to create more roles for each cube to implement the required level and granularity of security. For example, if you desire to allow universal access to your cube, you will need to create a role for this, such as TBI_<yourcube>_ALL, and map it into Teradata BI Repository by adding it to the list of Database Roles in the Schema Tree View.

Alternately, to provide restricted access by a subset of dimension, hierarchy, level, or level members, you need to create a role for that, such as TBI_<yourcube>_HIER_<HierRestriction1>, and map it into Teradata BI Repository. For example, you might create the roles TBI_SALES_HIER_REGIONWEST and TBI_SALES_HIER_REGIONEAST to control access to the Region hierarchy, the former with only access to the western region and the latter to the eastern region.

Teradata BI Repository supports the ability to map a Teradata security role into a given cube schema and allowing you to grant or deny access associated with this role. The list of usernames associated with a role is managed outside of Teradata BI Repository using normal database administration methods.

The DBA does not need to define restrictions on a cube's source table for a mapped role. Continuing with the previous example, you would create the roles TBI_SALES_HIER_REGIONWEST and TBI_SALES_HIER_REGIONEAST, assign user names to these roles and map these roles into your SALES cube using Teradata Schema Workbench. It is unnecessary to restrict access to the SALES source tables by these roles.

As an alternative to the normal role based cube security model, Teradata OLAP Connector and Teradata OLAP Server facilitate the use of existing user/role based database access control, already set up in the database, by utilizing trusted sessions when establishing query connections with the database. Trusted sessions ensure the actual end user's credentials are passed to the database to support role based access control. See Trusted Sessions.