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 Data Modeler Navigator Edition to access the database.
Note: The owner of the database (dbo) always supersedes any security provided on the mart. If the database owner is assigned the Viewer profile, that user is still able to change security profiles because the database owner is the Mart Administrator by default, regardless of the profile assigned in the Security Manager.
| Copyright © 2011 CA. All rights reserved. | Email CA Technologies about this topic |