Preparing Model Generator input files

  • Article

 

Applies To: Forefront Identity Manager

Microsoft BHOLD Model Generator creates a role model in BHOLD Core by accepting information about your organization’s structure, users, applications, and job functions and then linking them into a coherent role model that you can then use to control access to your organization’s applications and data. This information is provided in structured input files that you create and supply to Model Generator. You can create a basic role model by using three files (organizational unit, user, and permission application) or a more complete role model by adding two more files (role and account permission). For details on how these files are structured, see BHOLD Model Generator file formats in Microsoft BHOLD Suite Technical Reference. This topic provides additional information about creating and using these files. It contains the following sections:

  • Preparing the organizational-unit file

  • Preparing the user file

  • Preparing the permission-application file

  • Preparing the role file

  • Preparing the account-permission file

Preparing the organizational-unit file

The organizational-unit (orgunit) input file is required in both three-file and five-file sets, and it defines the orgunits in your role model. These orgunits can mirror the hierarchical structure of your organization, or they can reflect different business functions (such as projects or cost-center structure), or a combination of these. The orgunit file can be a comma separated–value (CSV) text file, or it can be a worksheet named OU in an Excel workbook saved in .xls format.. The first row of the file must contain the following column heads:

  • OU_Key—Every row must have an entry in this column. Model Generator uses the entries in this column to identify the orgunit so the orgunit can be properly linked to other elements in the role model. The information in the entries is not included in the role model itself. You can use any combination of text and numbers. For example, to make it easier to keep track of the hierarchical relationship among orgunits, you could use a 1 for the first top-level orgunit, 1.1 for the first child orgunit of the parent (top-level) orgunit, and 1.1.1 for the first child orgunit of the second-level orgunit.

  • BHOLD_OU_Key—Every row must have an entry in this column. The entries in this column supply the name (description) of the orgunit in the BHOLD role model and are the names that will appear in the BHOLD Core portal.

  • Managers_CorperateKey—Although this column is required to be present in the orgunit input file, it is not necessary to supply a value for every row. This column is used to identify the person responsible for the orgunit, and should match an Employee_ID entry in the user input file. Model Generator adds Managers_CorperateKey as a custom attribute to the BHOLD orgunit object.

    Important

    The column name must be spelled exactly as shown. Note the nonstandard spelling of the word corporate.

  • SV_Role—Although this column is required to be present in the orgunit input file, it is not necessary to supply a value for every row. This entry specifies the supervisor (owner) role for the orgunit. If you supply a value and you are using a five-file set, it should match a Role_Name entry in the role input file. If you do not supply a value for this entry, Model Generator creates and links a supervisor role to the orgunit.

  • Parent_OU_Key—Although this column is required to be present in the orgunit input file, it is not necessary to supply a value for every row. This entry specifies the parent orgunit. If you supply a value, it must match an entry in the OU_Key column. If you do not supply a value, the orgunit will be linked as a child of the root orgunit.

In addition to these required columns, you can supply additional columns. Model Generator creates a custom attribute of the BHOLD orgunit object for each of these additional columns. For example, if you want to specify approvers for BHOLD FIM Integration, you can add a column named Approver1. (For information about using BHOLD FIM Integration, see Microsoft BHOLD FIM Integration Operations Guide.)

Preparing the user file

The user input file is required in both three-file and five-file sets, and it defines the users in your role model. These users are mapped to application accounts defined in the account-permission input file. The user input file can be a comma separated–value (CSV) text file, or it can be a worksheet named Users in an Excel workbook saved in .xls format.. The first row of the file must contain the following column heads:

  • Employee_ID—Every row must have an entry in this column. The entries in this column supply the default alias for users in the BHOLD role model and are used by Model Generator to identify the users when creating application accounts.

  • Managers_CorperateKey—Although this column is required to be present in the user input file, it is not used by Model Generator, and entries in the column are ignored.

    Important

    The column name must be spelled exactly as shown. Note the nonstandard spelling of the word corporate.

  • OU_Key_1—Every row must have an entry in this column. The entries in this column identify an organizational unit (orgunit) that the user belongs to. (Every user must belong to at least one orgunit.) An entry in this column must match a OU_Key entry in the orgunit input file.

  • Description—Every row must have an entry in this column. The entries in this column supply the users’ name, such as Linda Sledge or Tom Brown.

In addition to these required columns, you can supply additional columns. Model Generator creates a custom attribute of the BHOLD user object for each of these additional columns. For example, if you want to specify the user’s job title, you can add a column named Job_Title.

Preparing the permission-application file

The permission-application input file is required only in a five-file set, and it defines your organization’s applications and corresponding permissions. These permissions can be mapped to roles in the role input file. The permission-application file can be a comma separated–value (CSV) file, or it can be a worksheet named Permissions-Applications in an Excel workbook saved in .xls format.. The first row of the file must contain the following column heads:

  • Application_Name—Every row must have an entry in this column. The entries in this column specify the application for which a permission is being defined. Model Generator creates an application in the BHOLD role model for each unique name in the column.

  • Company—Although this column is required to be present in the permission-application input file, it is not used by Model Generator, and entries in the column are ignored.

  • Permission_Name—Every row must have an entry in this column. The entries in this column supply the names of permissions linked to the applications specified in the Application_Name column.

  • Permission_Description—Although this column is required to be present in the permission-application input file, it is not necessary to supply a value for every row. Values supplied in this column must be unique, but do not appear in the BHOLD role model.

  • Permission_Owner_ID—Although this column is required to be present in the permission-application input file, it is not necessary to supply a value for every row. Values supplied in this column do not appear in the BHOLD role model.

  • SV_Role—Although this column is required to be present in the permission-application input file, it is not necessary to supply a value for every row. The entries in this column specify a supervisor role for the permission. If a value is supplied, it should match the name of a role supplied in the role input file. If a value is not supplied, Model Generator creates and links a unique supervisor role for the permission.

In addition to these required columns, you can supply additional columns. Model Generator creates a custom attribute of the BHOLD permission object for each of these additional columns. For example, if you want to specify the permission’s potential business impact, you could create a column named BI.

Preparing the role file

The role input file is required only in a five-file set, and it defines roles in addition to or instead of roles that Model Generator automatically creates during the File Import stage. (See Model Generator overview to learn about Model Generator wizard stages.) These roles can be linked to organizational units (orgunits) as effective or proposed roles, or they can be linked to users based on user attributes. In addition, they can be linked directly to a permission. The role input file can be a comma separated–value (CSV) file, or it can be a worksheet named Roles in an Excel workbook saved in .xls format. The first row of the file must contain the following column heads:

  • Role_Name—Every row must have an entry in this column. The entries in this column specify the name of the role being defined in the row.

  • Permission_Name—Although this column is required to be present in the role input file, it is not necessary to supply a value for every row. The entries in this column identify a permission that Model Generator will link to the role. If you do not supply a value in this column for a role, Model Generator creates the role, but does not link a permissions to the role. If you supply a value in this column, you must specify the permission’s application in the Application_Name column.

  • Appliction_Name—You must supply a value in this column if you supply a value in the Permission_Name column in the same row. The entries in this column identify the application of the permission specified in the Permission_Name column.

  • Role_Type—Although this column is required to be present in the role input file, it is not necessary to supply a value for every row. If an entry in this column is set to Supervisor, Model Generator creates the role as a supervisor role.

    Note

    This column does not set the Role Type attribute of the BHOLD role object.

  • ABA_Attribute—Although this column is required to be present in the role input file, it is not necessary to supply a value for every row. The entries in this column specify the name of an attribute that Model Generator will use to create an attribute-based (ABA) role. For example, if you want to create an attribute-based role for all users that have their Job_Title attribute set to Manager, you would enter Job_Title in this column. If you supply a value in this column, you must also supply a value in the ABA_Operator and ABA_Value columns in the same row.

  • ABA_Operator—You must supply a value in this column if you supply a value in the ABA_Attribute column in the same row. The entries in this column specify the type of logical operator that Model Generator will use when evaluating the value of the attribute specified in ABA_Attribute. The operator must be one of the following:

    • = (is equal to)

    • > (is greater than)

    • < (is less than)

    • <= (is less than or equal to)

    • >= (is greater than or equal to)

    • <> (is not equal to)

  • ABA_Value—You must supply a value in this column if you supply a value in the ABA_Attribute column in the same row. The entries in this column specify the value of the attribute being tested. For example, if the value in this column is Manager, the value in ABA_Attribute is Job_Title, and the value in ABA_Operator is <>, Model Generator creates an attribute-based role and links it to all users except those whose Job_Title is Manager.

  • Inherited_Role—Although this column is required to be present in the role input file, it is not necessary to supply a value for every row. The entries in this column specify whether the role can be inherited by lower levels in the orgunit hierarchy. Set this value to YES to allow the role to be inherited. Set it to NO to specify that the role cannot be inherited.

  • SV_Role—Although this column is required to be present in the role input file, it is not necessary to supply a value for every row. The entries in this column specify the supervisor role of the role defined in the same row. A value in this column should match a value in the Role_Name column of the role input file, and the matched role must have the Role_Type entry set to Supervisor. If you do not specify a value in this column for a row, the role being created will be linked to the default supervisor role.

  • Parent_Role_Name—Although this column is required to be present in the role input file, it is not necessary to supply a value for every row. The entries in this column identify the parent of the role named in the Attribute_Name column in the row. For example, if the Attribute_Name is set to Sales Manager—East, setting Parent_Role_Name to Sales Manager would make the Sales Manager—East role a child (subrole) of the Sales Manager role. Parent roles receive permissions from their subroles.

  • OU_Key—Although this column is required to be present in the role input file, it is not necessary to supply a value for every row. The entries in this column identify the orgunit that Model Generator will link the role to. Values in this column must match a value in the OU_Key column of the orgunit input file. If you supply a value in this column, you must supply a value in the OU_Link_Type column in the same row.

  • OU_Link_Type—You must supply a value in this column if you supply a value in the OU_Key column in the same row. The entires in this column specify the method that Model Generator will use to link the role to the orgunit specified in OU_Key. It can be either PROPOSED or EFFECTIVE.

In addition to these required columns, you can supply additional columns. Model Generator creates a custom attribute of the BHOLD role object for each of these additional columns. For example, if you want to specify a role approver for use by BHOLD Attestation, you could create a column named Approver1. (For information about BHOLD Attestation, see Microsoft BHOLD Attestation Operations Guide.)

Preparing the account-permission file

The account-permission input file is required in both three-file and five-file sets, and it defines the application-specific user names for the users in your role model. For example, a user named Kim Kerbo might have the default alias kimkerbo in BHOLD and the alias kerbokim in Active Directory. The account-permission file lets you map BHOLD users to application accounts. You can also assign roles to users or specify permissions for each user that can be linked to the user’s personal role when it is created by Model Generator, and you can designate an application-specific role that is linked to the user. The account-permission input file can be a comma separated–value (CSV) text file, or it can be a worksheet named Accounts-Permissions in an Excel workbook saved in .xls format. The first row of the file must contain the following column heads:

  • Employee_ID—Every row must have an entry in this column. The entries in this column specify the default alias for users in the BHOLD role model and are used by Model Generator to identify the users when creating application accounts. Each entry in this column must match an entry in the Employee_ID column of the user input file.

  • Account—Although this column is required to be present in the role input file, it is not necessary to supply a value for every row. The entries in this column specify the user name (alias) of the user for the application specified in the Application_Name in the same row. If this value is omitted, Model Generator links the user identified by Employee_ID to the role specified by Role_Name.

  • Application_Name—Every row must have an entry in this column. The entries in this column specify the application for which an account is being created or the permission being linked to the user’s personal role (or both). Model Generator creates the application in the BHOLD role model if it does not already exist.

  • Permission_Name—Although this column is required to be present in the role input file, it is not necessary to supply a value for every row. The entries in this column specify a permission that Model Generator will link to the personal role that Model Generator creates for the user identified by Employee_ID or to an application-specific role specified in the Role_Name column in the row. When the account-permission input file is used as part of a five-file set, entries in this column should match entries in the Permission_Name column of the permission-application input file. If there is matching entry in to the permission-application file, or if the account-permission file is being used in a three-file set, Model Generator creates the permission and links it to the user’s personal role or to an application-specific role specified in the Role_Name column of the row.

  • Role_Name—Although this column is required to be present in the role input file, it is not necessary to supply a value for every row. The entries in this column specify the name of an application-specific role that Model Generator will create and link to the user. If an entry is specified in the Permission_Name column in the same row, the specified permission is linked to the role.

Next step

Creating the Model Generator input files is the by far the bulk of the effort required to prepare for running Model Generator. Before you do so, however, you need to plan how you will use each of the Model Generator stages to refine your role model. For details on this process, see Before you begin.

See also