This documentation supports the 9.0 version of BMC Atrium Single Sign-On, which is in "End of Version Support." However, the documentation is available for your convenience. You will not be able to leave comments.Click here to view the documentation for a supported version of Remedy Single Sign-On.

Federating user accounts in bulk


In order for users to do single sign-on between an Identity Provider (IdP) and a Service Provider (SP), the user accounts must be federated, or linked together. When an account is federated, the two systems agree on a common identifier for a user. The common identifier is used when the systems communicate about the user. In this way, account names do not need to be shared between the two systems. Instead, a unique name specific to the federated identity is agreed upon by the two systems.

Note

If bulk federation is not used, then when a user first tries to access a BMC product that is integrated with a BMC Atrium Single Sign-On SP, the user follows a two-step process to create a federated account. First, the user authenticates with the IdP and then the user authenticates with the SP.

The following topics provide basic information and instructions for federating user accounts in bulk:

The following topics provide additional information for federating user accounts in bulk:

bulkFederation utility syntax

Bulk federation is accomplished by using the bulkFederation utility with the following syntax:

(Microsoft Windows) bulkFederation.bat <command> <arg1> ...< argN>
(UNIX) bulkFederation.sh <command> <arg1> ... <argN>

bulkFederation utility commands

The following bulkFederation utility commands are used for bulk account federation:

 

 

To perform bulk federation

  1. Provide either an identity list file or an identity mapping file.
    • An identity list file is simple text file with only your local user IDs.
    • An identity mapping file is a simple text file with both your local user IDs and your remote user IDs.
  2. Create user accounts on each server (local and remote) with the createcommand.
    • Use either your identity list file or your identity mapping file as the input file on the local server.
    • Use a separate identity list file or your federated mapping file on the remote server.
       For example (UNIX):
      bulkFederation.sh create -ap myAdminPassword -au amAdmin -rf myDiagnosticFile1 -um userIdMapFile.dat

      In this example, an identity mapping file, userIdMapFile.dat, is used.
  3. Federate the user accounts on the local server with the federatecommand.
    • Be sure that your user accounts were created on each server (local and remote).
    • Use your identity mapping file as the input file and provide a file name for the output file that will contain the federated identity mapping data.
       For example (UNIX ):
      bulkFederation.sh federate -ap myAdminPassword -au amAdmin -fm /BmcRealm/sp -nm nameIdMapFile.dat -re IdP -rf myResultsFile2 -um userIdMapFile.dat

      In this example, nameIdMapFile.dat is the output file for the federated identity mapping data that is generated by the federate command.
  4. Copy the federated identity mapping data file to the remote server.
  5. Import the federated identity mapping data into the remote server with the import command.

    The federated identity mapping data file is the output file from the federate step and becomes the input file for the import step.
     For example (UNIX ):
    bulkFederation.sh import -ap myAdminPassword -au amAdmin -im /BmcRealm/idp -nm nameIdMapFile.dat -rf myResultsFile3

    In this example, nameIdMapFile.dat contains the federated identity mapping data that is generated by the federatecommand and imported into the remote server.

    Note

    Alternatively, you can use the create-federate command to replace the separate create and federate steps and the create-import command to replace the separate create and import steps.

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*