Security Profiles - Teradata Meta Data Services

Security Profiles

A security profile is a named object containing the permissions for a set of groups and users. One and only one Security Profile is assigned to each object in the repository. Access to the object is based on the access type permissions defined in the assigned Security Profile. The ID of the Security Profile will be stored in a common property of every object.

One Security Profile can be assigned to many objects.

Figure 20 is an example of a Security Profile.

Figure 20: Security Profile Example 1

Access to objects in MetaSurf, MetaBrowse or other MDS applications is based on the access type in the Security Profile associated with the object. If an object is not given public read access, a user will not be able to see the object unless specifically granted access as a user or as a member of an application group in the Security Profile for that object.

In the example in Figure 21, Mary, Fred and all users in the Acct and Payroll Application Groups have read permission to databases A and B. Fred and all the users in the Payroll Application Group can update objects corresponding to databases A and B.

Lucy and all users in the Application Group Acct have read and write access to databases C and D. No other users can view these databases.

Figure 21: Security Profiles Example 2

It is possible for a user can have multiple access rights defined in the profile. In the above example, user Mary has been granted explicit Read rights. If Mary is also a member of the Payroll group, she will also have Full rights. The user will be granted the highest level of rights (in this case, Full rights).

There will be one special term that can be used to define rights in a Security Profile. The term is “Everyone.” Everyone specifies permissions for anyone connecting to the MDS repository.

Security on Security Profiles

Access to security profiles will be as follows:

Any MDS user can create a security profile

The creator of a security profile can set the owner of the profile

Users that are granted read access in the security profile are given read permission to the security profile.

Default Profiles

The MDS system will have a configurable default security profile. Initially the profile will be:

User	Access Type
Everyone	Read

The Default Security Profile can be changed in the MetaManager GUI.

If a Security Profile is not specified for an object when created in the MDS repository, it will be given a default profile. The default profile will depend on the type of object being created. Figure 22 illustrates the defaults:

Figure 22: Security Profile Defaults

Preconfigured Profiles

MDSDefaultSecurityProfile

The MDSDefaultSecurityProfile defines the permissions to all objects which are not assigned a specific security profile. The initial setting will be (Everyone, Read). Only metasu or another superuser can change the permissions. The profile cannot be deleted.

MDSMetaModelSecurityProfile

The MDSMetaModelSecurityProfile is assigned to the MDSMetaModel AIM components. The MDSMetaModel security profile determines who can create metamodels, classes and relationships The initial setting will be (Everyone, FULL). Permissions on MDSMetaModel components are:

Updates and deletes to MDSMetaModel objects are not permitted by any user (including metasu or other superuser).

The MDSMetaModel security profile determines who can create metamodels, classes and relationships. A user must have FULL permission in the MDSMetaModelSecurityProfile to create a model, class, relationship or property.

To view the MDSMetaModel components, a user must have READ permission in the MDSMetaModelSecurityProfile.

Only metasu or another superuser can change the permissions. The profile cannot be deleted.

DIMSecurityProfile

The DIMSecurityProfile is assigned to the DIM AIM components. The initial setting will be (Everyone, Collection). Permissions on DIM components are:

To add a class or relationship to the DIM, a user must have FULL permission in the MDSMetaModelSecurityProfile and COLLECTION permission in the DIMSecurityProfile.

To view the DIM AIM components, a user must have READ permission in the DIMSecurityProfile.

Only metasu or another superuser can change the DIM permissions. The profile cannot be deleted.

This is not the security profile which will be assigned to DIM class objects. This profile is only for the DIM AIM objects.

Special Permissions on AIM Components

Metasu, or any superuser, through the MetaManager, will be able to change the Security Profile on AIM components. Otherwise updates to AIM objects are not permitted.

The Security Profile assigned to a Class Description determines what users can create objects of that class type. The user must have FULL permission in the profile.

The Security Profile assigned to each AIM component determines who can read the object. The user must have READ permission in the profile.

Only the owner of the AIM component can delete it.

To create a class in a model which is owned by another user, a user must have FULL permission in the MDSMetaModel security profile and COLLECTION permission in the model’s security profile.

To create a relationship in a model which is owned by another user, a user must have FULL permission in the MDSMetaModel security profile, COLLECTION permission in the model’s security profile and COLLECTION permission to the classes which are defined in the relationship.

To create a property in a class which is owned by another user, a user must have FULL permission in the MDSMetaModel security profile and COLLECTION permission in the class security profile.

Only the owner of a class can remove property descriptions in the class.

Creating Objects in a Class

To create an object in a class, the user must be the owner of the class description object or have FULL permissions in the security profile which is assigned to the class description object.

Authentication

Authentication is the system identifying a user based on user id and password. MDS will authenticate users when they attempt to connect to the repository. Only valid users will be allowed access to the repository.

When a user initializes access to the MDS repository, the user must provide his/her user id and password. MDS will encrypt the password provided by the user and compare it to his encrypted password stored in the repository. If the passwords match, the user will be allowed access to the repository.