Inherited Security Permissions

Security permissions for classes that are lower in the hierarchy automatically inherit the security permissions from classes that are higher in the hierarchy, unless specifically overridden by another security profile. For example, if you assign a user the Architect profile for the mart level, the user is automatically assigned Architect-level permissions for all object classes (libraries, diagrams, objects, and properties) below it in the object hierarchy. In this arrangement, you can assign a global security profile to a user at the mart level, and then grant or deny additional permissions in lower-level object classes by assigning a different security profile.

You can also assign a security profile to a user for an individual object. A security profile assigned to a specific object overrides any security permissions inherited from a higher-level object class. If you assign a user to a new security profile, the user retains all permissions granted by other security profiles, except for the permissions that are overridden by the new security profile.

By default, the Viewer and Guest security profiles are read-only security profiles at the mart level. When a user is assigned to a read-only security profile, the permissions defined in that profile are automatically applied to all lower object classes in the database. While you can assign the Viewer profile to limit the permissions of a user in a particular object class, you should use the Guest profile exclusively for users that are using CA ERwin Model Navigator to access the database. CA ERwin MM users who are granted a Guest profile do not take up a license. Viewer users do take up a license.

Note: The db_owner of the database always supersedes any security CA ERwin MM provides on the mart. If the db_owner is assigned the Viewer profile, it is still able to change security profiles because the db-owner is the mart administrator by default regardless of the profile assigned in the Security Manager.