Importing permissions, users, and roles

This topic describes how rules available in BMC Atrium Orchestrator Platform 7.6.03 are imported in BMC Atrium Orchestrator Platform 7.9.x environment using the migration tool. 

Rules in BMC Atrium Orchestrator Platform 7.6.03 can only be written against built-in and user-defined roles.

When rules are imported into the BMC Atrium Orchestrator 7.9 CDP or repository, the following conditions occur:

• Rules written against built-in roles are not imported.  
  This may be overridden through the use of role mappings.
• Only those rules written against user-defined roles are imported.
• Access Manager mapped roles are treated as "alternate names" for the built-in or user-defined roles to which they're mapped and treated, for rule import, as Mapping File mapped roles.
• For each role designated by an "alternate name" by a Mapping File (or Access Manager) mapped role, the rules written against the "original" role are imported as rules for the "alternate name".

The following exceptions exist while importing rules:

• Rules written against the AoAdmin role are not imported. The default rule sets used in BMC Atrium Orchestrator 7.9 include non-modifiable rules that permit AoAdmin access to everything.

• Every role for which rules are imported receives the CDP rules permitting USER role access.
  Users belonging to the USER role do not get access to the repository. USER is a special role in BMC Atrium Orchestrator 7.6 to which every authenticated user implicitly belongs.  
  In BMC Atrium Orchestrator 7.9, there is no substitute role to the USER role so every role must be granted what USER can do. 

  Note

  Achieving true parity with the BMC Atrium Orchestrator 7.6 USER role, you need to create a role in BMC Single Sign-On (SSO) to which all of BAO users belong and, associate that "all users" role with USER by using the mapping file.

  For more information, see Using a role mapping file to import default roles.

• After importing the permissions, the ADMIN role from 7.6.03 does not have all permissions, because the default admin role in 7.9 is AoAdmin. The AoAdmin role in 7.9 is assigned all permissions. 

Importing permissions into a repository

When importing permissions in the repository, the following elements are imported:

• Repository operation/artifact access rules
• Roles for which rules are defined

When importing repository access rules, administrative-level rules are created for every role mapped to the AO 7.6 ADMIN and REPOSITORY_ADMIN roles.  

Importing rules into the repository is governed by whether an existing repository content database is used or not.  If an existing Repository content database is used, rules should be imported into the Repository before it is started for the first time. If a new Repository content database is used, then content must be migrated into the new Repository before rules are imported.

Importing rules into the repository sets the permissions associated with the Default role to their initial, permissive values. Following an import, the repository permissions should be reviewed and adjusted as necessary to conform with the local needs.

Importing permissions into a CDP

When importing into a CDP, the following is imported:

• CDP operation rules
• CDP process execution rules
• Roles for which rules are defined 

Rules granting rights to the AO 7.6 role USER are imported into every role imported into the CDP.  In AO 7.6, every user authenticated to AO is associated with the role USER, so rights granted to USER are available to all logged-in users.  In AO 7.9, the concept of the USER role does not exist – there is no role with which all authenticated users are associated.

Importing rules into the CDP is expected to be done before the CDP is started for the first time. Imported rules will persist in Grid Manager until the Grid Manager permissions UI is used to alter one or more permissions.  The Grid Manager permissions UI cannot be used to display rules for modules not installed in the grid – rules for modules not active on the grid are not displayed.  Once permissions are modified, only rules governing access to installed content are retained – rules imported for modules not yet loaded in the CDP are lost.  When you start the CDP following a rules import, all modules governed by the imported rules should be activated on the grid before using Grid Manager to make changes.

Importing rules into the CDP sets the permissions associated with the Default role to its initial, permissive values.  Following an import, the CDP permissions should be reviewed and adjusted as necessary to conform to local needs.

Importing users and roles into BMC Single Sign-On (SSO)

When importing into either a Repository or a CDP and an --rssoPassword option value is provided, the following is imported into SSO:

• Users exported from Access Manager
• User-defined roles exported from Access Manager
• Roles specified, in a role mapping file, as alternate role names for built-in and user-defined roles exported from Access Manager
• Role membership reflecting the membership as exported from Access Manager

Definitions for users already defined in SSO or known to SSO through an external definition are not altered.  User passwords can not be exported from Access Manager so a generated password is used during import. The password for an user imported into SSO is set to the userid padded, as necessary, with "12345678" to create a password of the minimum length required (default: 8 characters).For example, the user named 'sam' will be assigned a password of 'sam12345'.  The minimum password length is defined by SSO.

In SSO, a role may be defined within SSO or known to SSO through an external definition.  When importing a role definition, a role definition is not added to SSO if SSO knows of an external definition.  Role membership is updated only for roles defined within SSO (or added during import) and only with users defined within SSO (or added during import).

It is safe to provide the --rssoPassword option for both Repository and CDP import operations as neither users nor roles will be imported more than once and role membership is updated only if necessary.

It is possible for a principal (user or role) to be both defined within and defined externally to SSO though though duplicate definition is usually something undesired in a security environment. The distinction between defined within and defined externally turns out to be an important one for import processing.