DOCS

Managing Roles

Roles are sets of permissions granted to users in several different domains. Unlike users, roles are independent from domains. Therefore, you can create a role before creating the domain(s) in which one or more users will have this role.

Within each role, you can grant or deny one or more functional permissions, define access rights to the packages and type groups specifically to the role, and associate a Welcome Panel that all related users will inherit from the role created.

Each role can be granted these functional permissions:

Permission	Description
Super	This permission is for the superuser system user. It bypasses all permission settings (that is, even if an administrator explicitly denies access rights to a role having Super permission, users [administrators] who inherit this role will still have access).
Admin	This permission specifically allows you to perform the repository management tasks (that is, under Repository Management in the administration page of becubic Web) except the Web site management.
AdminDatabase	This permission specifically allows you to manage the database in the becubic Web administration page (that is, Database Administration).
AdminExtensions	This permission specifically allows you to manage the extensions (for example, CAE entry point connection or Full Text Engine).
AdminSecurity	This permission specifically allows you to manage user/security settings in the becubic Web administration page (that is, Security Management).
AdminWeb	This permission specifically allows you to manage the Web site settings (that is, tasks under Security ManagementRepository AdministrationWeb Site Management) and to use the monitoring tools.
AllInstances	This permission allows you to use the All Instances feature.
AllReferences	This permission allows you to use the All References feature.
APM	This permission allows you to perform APM-related operations (for example, calculating the metrics).
ArbitraryQueries	This permission allows you to enter arbitrary queries on the Advanced tab of the Quick Search option.
Eclipse	This permission allows you to use the becubic Eclipse client GUI.
Feed	This permission allows you to execute the repository feeding process. It is also an object creation/update operation, which includes Write permission. If you deny Feed permission to an advanced or administrator user and, at the same time, grant Write permission on individual objects, you must explicitly allow Write permission.
Glossary	This permission allows you to see the related glossary terms. In addition to the permission, a glossary connection must be configured to be able to see the related glossary terms.
History	This permission allows you to see the historical data (for example, applying a snapshot view).
I/O	This permission allows you to perform import/export (including the Export to DES function) operations.
Impact	This permission allows you to edit and run the data propagation operations.
Panel	This permission allows you to edit Welcome Panels and to add/remove objects on the panel by drag-and-drop.
Permissions	This permission allows you to edit the object/type permission setting.
Properties	This permission allows you to open the Properties window, which shows all the properties and references of the selected object.
Query	This permission allows you to edit and run queries.
QuickSearch	This permission allows you to perform quick searches.
Report	This permission allows you to edit and generate becubic reports.
Set	This permission allows you to open the Set Browser and perform operations on sets.
Source	This permission allows you to use the View Sources function.
TypeBrowsing	This permission allows you to use the Type Browser view.
Web	This permission allows you to use the becubic Web GUI.
Write	This permission allows you to save objects to the becubic repository. If this permission is denied, the user can only view repository contents.
WritePassword	This permission allows you to change your password even if you do not have Write permission. You can change only the password for the becubic user account. The database user password and the LDAP user password cannot be changed from within becubic.
WriteProfile	This permission allows you to edit your user preferences even if you do not have Write permission.

Roles also can be hierarchically structured by specifying one or more super roles or sub roles. See Structuring Roles Hierarchically.

See Security Management Procedures for step-by-step procedures for performing the various user and security management tasks. See System Roles.

Default Roles

becubic is initialized with these default roles:

Default Role	Description
Administrator	This role has all permissions but Super. It also allows access to all packages and type groups.
Architect	This role is specific to Application Portfolio Management.
Business Analyst	This role is specific to Application Portfolio Management.
CIO	This role is specific to Application Portfolio Management.
Director	This role is specific to Application Portfolio Management.
Guest	This role has GUI permission and can view Analysis packages and Analysis type groups. By default, this role can view the becubic Web GUI and access a repository through the becubic Eclipse client.
Integration	This role has feed permission and can create and update objects of any type. It does not, however, have GUI permission (that is, it does not enable users to access repositories through the becubic Eclipse client or the Web GUI). This role is dedicated to Ant-based operations in batch mode.
No Access	This role denies all permissions and is specifically to be used as the default role for any LDAP user that is not recognized.
Project Manager	This role is specific to Application Portfolio Management.
QA Manager	This role is specific to Application Portfolio Management.
Standard	This role has GUI permission and can view all packages and Analysis type groups. By default, this role can view the becubic Web GUI and access a repository through the becubic Eclipse client.
Super	This role enables superuser to bypass any limitation and manage everything in a repository.
VP	This role is specific to Application Portfolio Management.

Structuring Roles Hierarchically

You can specify super roles or sub roles to define hierarchies of roles, which enable you to implement these user management methods:

User profiles, similar to user groups, obtained by combining sub roles under main roles.
Inheritance, which enables you to add becubic-specific permissions to SSO-authenticated user roles.

Rules for Inheriting Permissions

You can define a role hierarchy with multiple paths. If different paths reach the same role, becubic calculates the shortest path to determine the inheritance level of the role.

A user inherits permissions according to these rules:

The applied permission setting is inherited from the highest level role. For example, in the following illustration, Deny is applied as inherited from Role R2.
If a permission is both allowed and denied by two different roles at the same level, Deny is applied.
If no permission setting is explicitly assigned, Allow is applied.

Example of a Role Hierarchy for Permissions

Super role and sub role are reverse roles automatically managed by becubic. You need to specify only one of them to define a role hierarchy.

Rules for Inheriting Business Name Definitions

A user inherits business name definitions according to these rules:

Business name definitions, like permissions, are associated with roles. When a user inherits several different business name definitions through multiple roles, the applied business name definition is the one that is inherited from the highest level role.
If several different business name definitions are inherited from the same level of a multi-branch inheritance tree, a conflict occurs and the business names are ignored.

See the ASG-becubic Installation and Implementation Guide for information about the business name feature.

Managing Object or Type Permissions for a Role

You also can set permissions on specific repository objects (see Setting Permissions on Repository Objects).