Authentication Management

Administration > Users > Authentication Management

Alternatively, click Authentication Management.

Single Sign-On (SSO) is a method of access control that enables a user to log in once and gain access to the resources of multiple software systems without being prompted to log in again. The applications inside the configured group of software systems trust the authentication, and you do not need further authentication when moving from one application to another.

By default, the Single Sign-On (SSO) authentication for OMi is not configured. This way, users can access multiple OMi environments by using the same client machine and internet browser. If you do not intend to integrate OMi with other systems, HPE recommends to use the default. If you do integrate, turn on LW-SSO or IDM-SSO instead. For details on the SSO configuration, see How to configure SSO authentication.

LW-SSO is an optional Single Sign-On authentication strategy for OMi. LW-SSO is embedded in OMi and does not require an external machine for authentication. For details on LW-SSO, see Lightweight Single Sign-On authentication.

If the applications configured outside of OMi do not support LW-SSO, or if you want a stronger Single Sign-On implementation, you can configure Identity Management Single Sign-On (IDM-SSO) by using the Single Sign On Editor panel. When enabled as a Single Sign-On strategy, IDM-SSO also serves as an authenticator. For details on IDM-SSO, see Identity Management Single Sign-On authentication.

Identity Management Single Sign-On authentication

Identity Management Single Sign-On (IDM-SSO) provides a more secure connection than that offered by LW-SSO. It also can be used if the applications configured outside of OMi do not support LW-SSO.

IDM server

The IDM server is monitored by a single center Policy Server, and consists of a User Repository, a Policy Store (both could reside over the same server as the policy server), and a Web Server Agent installed over each of the application's web servers communicating with the Policy Server. The IDM server controls users' access to various organizational resources, protecting confidential personal and business information from unauthorized users. For details, see your IDM vendor's documentation.

Storing user information

OMi requires the IDM vendor to store user information to render it available as a header on HTTP requests. You configure both the HTTP header name and the IDM-SSO strategy in the Single Sign On Editor panel. For details, see Identity Management Single Sign-On authentication.

IDM login

Before configuring IDM-SSO in OMi, make sure you have restarted the web service and that you have an OMi user with super administrative permissions existing in the IDM user repository.

1. Make sure you see your IDM dialog box before the OMi login screen. For details, see your IDM vendor's documentation. At this point, you can still access OMi directly through the OMi login screen.

2. To configure IDM-SSO in OMi, you need the header name passed by the IDM-SSO solution (for example, sso_user). Ask your IDM-SSO administrator for the header name supplied by IDM.

3. To verify the header, go to http://<gateway server>/topaz/verifyIDM.jsp?headerName=<IDM SSO Header Name> in the same user session. If the header is correct, the system displays the user name of the current user (provided that IDM authentication was performed prior to this action) in green.

4. When the header is verified as correct, use it in the Single Sign On Editor panel in OMi. For more information on configuring Identity Management Single Sign-On, see How to configure SSO authentication.

• Note: LDAP is not used for authentication when you select IDM-SSO as your authentication strategy. If you have LDAP automatic user creation enabled, LDAP can still be used to synchronize OMi users with users configured on the external LDAP server, and to map OMi groups to LDAP groups. If LDAP is disabled, or LDAP is enabled without automatic user creation, you must manually create all users, groups, and roles. For more information on LDAP, see LDAP authentication.

Securing OMi resources under IDM-SSO

When using IDM-SSO as a Single Sign-On strategy, OMi resources may be protected with form or basic authentication schemes, or left unprotected.

Resources accessed by application users

If you want to use IDM-SSO to secure OMi resources accessed by application users, use form authentication on the following resources:

• /filters/*

• /hpbsm/*

• /mam-images/*

• /mcrs/*

• /MercuryAM/*

• /odb/*

• /opal/*

• /opr-admin-server/*

• /opr-console/*

• /opr-gateway/*

• /opr-config-server/*

• /opr-web/*

• /ovpm /*

• /topaz/*

• /topazSettings/*

• /ucmdb-ui/*

• /uim/*

• /webinfra/*

Example of URL with form authentication

• The following URL verifies that the IDM header is correct:

  https://<gateway server>/topaz/verifyIDM.jsp?headerName=<IDM SSO Header Name>

  Expected Result: The system displays the user name of the current user (provided that SM authentication was performed prior to this action).

Resources accessed by data collectors

If you want to use IDM-SSO to secure OMi resources accessed by data collectors in machine-to-machine communication, use an authentication method that allows passing credentials, or basic authentication.

The following resources are used by data collectors, connected servers, and load balancers:

• /ext/*

• /mam/* — used by RTSM

• /topaz/topaz_api/* — used by all data collectors to get OMi version, server time, and so on

Example of URL with basic authentication

• The following URL may be used by connected servers to establish a connection to OMi:

  https://<gateway server>/opr-gateway/rest/event_list

  Expected Result: The system displays the basic authentication window followed by the result.

Resources accessed by web services (required)

If you use IDM-SSO with OMi, you must protect the following resources with basic authentication as they are used by various OMi web services:

• /opr-admin-server/rest/*

• /opr-console/rest/*

• /opr-gateway/rest/*

• /opr-web/rest/*

• /opr-config-server/rest/*

• /topaz/bam/*

• /topaz/bsmservices/*

• /topaz/servicehealth/*

• /opr-web/admin/rest/*
• /OVPM/rest/*

Additional resources to be protected with basic authentication

• /topaz/sitescope/* — used for the SiteScope integration with OMi

Unprotected resources

The following resources should remain unprotected:

• /mam-collectors

• /topaz/Charts

• /topaz/images

• /topaz/Imgs/chartTemp

• /topaz/js

• /topaz/services/technical/time

• /topaz/static

• /topaz/stylesheets

• /ucmdb-api

If you are using a load balancer, you should also unprotect the following resources:

• /topaz/topaz_api/loadBalancerVerify_core.jsp

• /topaz/topaz_api/loadBalancerVerify_centers.jsp

Lightweight Single Sign-On authentication

LW-SSO is an optional single sign-on authentication strategy for OMi. LW-SSO is embedded in OMi and does not require an external machine for authentication. OMi currently uses version 2.4 of LW-SSO.

LW-SSO is a method of access control that enables a user to log on once and gain access to the resources of multiple software systems without being prompted to log on again. The applications inside the configured group of software systems trust the authentication, and there is no need for further authentication when moving from one application to another.

The information in this section applies to LW-SSO version 2.4.

• LW-SSO Token Expiration

  The LW-SSO Token's expiration value determines the application's session validity. Therefore, its expiration value should be at least the same value as that of the application session expiration value.

• Recommended Configuration of the LW-SSO Token Expiration

  Each application using LW-SSO should configure token expiration. The recommended value is 60 minutes. For an application that does not require a high level of security, it is possible to configure a value of 300 minutes.

• GMT Time

  All applications participating in an LW-SSO integration must use the same GMT time with a maximum difference of 15 minutes.

• Multi-domain Functionality

  Multi-domain functionality requires that all applications participating in LW-SSO integration configure the trustedHosts settings (or the protectedDomains settings), if they are required to integrate with applications in different DNS domains. In addition, they must also add the correct domain in the lwsso element of the configuration.

• Get SecurityToken for URL Functionality

  To receive information sent as a SecurityToken for URL from other applications, the host application should configure the correct domain in the lwsso element of the configuration.

Note Lightweight Single Sign-On (LW-SSO) Authentication Support enables users to log into OMi automatically and securely without needing to enter a user name and password.

Configuring LW-SSO

You can configure LW-SSO in OMi by using the Single Sign On Editor panel. For more details , see How to configure SSO authentication.

LW-SSO can be configured by using the JMX console to accept client-side authentication certificates. When a certificate is recognized, LW-SSO creates the token to be used by other applications. For details, see Using client-side authentication certificates for secure user access to OMi.

Note After the configuration, you must restart either the JBoss process or the OMi server.

Working with LW-SSO

OMi can be configured with Lightweight Single Sign-On (LW-SSO). With LW-SSO, once you log in to OMi you automatically have access to other configured applications, without needing to log into those applications.

When LW-SSO Authentication Support is enabled, you must ensure that the other applications in the Single Sign-On environment have LW-SSO enabled and are working with the same initString. If the applications are in different domains, the domains must be trusted domains.

Using client-side authentication certificates for secure user access to OMi

You can provide user access to OMi using client-side authentication certificates. This provides a secure alternative to entering a user name and password to log in.

From the Single Sign On Editor panel, you can configure LW-SSO to accept such certificates. When a certificate is accepted, users are automatically logged into OMi if the client certificate card is inserted in the machine. If LW-SSO is configured to accept certificate, users are not able to login to OMi without the client certificate card. For information about the Single Sign On Editor panel, see How to configure SSO authentication.

For Smart Card configuration instructions, see Configure Client Certificate or Smart Card Authentication.

Using an external authentication point for secure user access to OMi

LW-SSO 2.4 enables you to use an external authentication point. This allows you to use your own credential validation method, for example LDAP, a proprietary user/password database, or a custom SSO solution.

The external authentication point is an external URL that performs the actual user authentication. It obtains the user credentials (usually the user name and password, but it could be something else, such as the user's class-B certificate, or a proprietary SSO token), validates these credentials, and then creates an "authentication assertion", a token that states who the authenticated user is. The authentication assertion usually also provides information about how the user was authenticated.

For information about configuring an external authentication point for secure access to OMi, see How to configure LDAP authentication.

LW-SSO configuration for multi-domain and nested domain installations

LW-SSO configuration, set in the Single Sign On Editor panel (for details, see How to configure SSO authentication), depends on the architecture of your OMi installation.

If you log into OMi through a man-in-the-middle, such as reverse proxy, a load balancer, or NAT, the OMi domain is the domain of the man-in-the-middle.

If you log in directly to the OMi Gateway, the OMi domain is the domain of the OMi Gateway.

For LW-SSO to work with another application in a domain different from the OMi domain, all of these domains must be listed in the Trusted Hosts/Domains list of the LW-SSO configuration.

If your OMi domain and integrating application are located in nested domains, then the suffix of the domain should be the defined as the LW-SSO domain for both applications. In addition, you should disable automatic domain calculation (Parse automatically in the Single Sign On Editor panel) and explicitly state the domain suffix.

Note To use LW-SSO for integrations of products that reside in different domains and require a cross launch, enable LW-SSO for both products. Configuration for multiple domains must be supported in both products. For details, see the Integrate section.

Example 1:

OMi gateway server is located in emea.example.com
TransactionVision server is located in cnd.example.com
Disable automatic domain calculation and set domain name = example.com

Example 2:

OMi gateway server is in corp.ad.example.com
NNMi server is in sdc.example.com
Load balancer is in example.com
Disable automatic domain calculation and set domain name = example.com

The Lightweight Directory Access Protocol (LDAP) is an internet protocol that email and other programs use to look up information from an external server. LDAP can be configured with OMi in the following ways:

• As an authentication mechanism for users logging into OMi.

• To synchronize OMi users with users configured on the external LDAP server, and to map OMi groups to LDAP groups, thereby simplifying the process of user management for OMi administrators. For information, see Synchronizing users, and Mapping groups.

Automatic user creation from LDAP servers and mapping groups in OMi simplifies the user management process for administrators, as all of the user management functions are performed through the LDAP server.

When LDAP authentication is enabled, you can access LDAP Connections and the LDAP Mapping Settings editor directly from the Users, Groups, and Roles page:

Administration > Users > Users, Groups, and Roles > LDAP

Alternatively, click Users, Groups, and Roles.

You can configure LDAP by using the LDAP Configuration panel. For details, see How to configure LDAP authentication.

LDAP authentication overview

You can use one or more external LDAP servers to store user information (user names and passwords) for authentication purposes, instead of using the internal OMi service. You can manually create LDAP users, and use LDAP servers to automatically create OMi and LDAP users and map LDAP groups to groups in OMi.

For optimal performance, HPE recommends that LDAP servers be in the same subnet as the rest of the OMi servers.

For optimal security, it is recommended to either configure a TLS connection between the OMi gateway server and the LDAP server, or to have OMi servers and the LDAP servers on the same secure internal network segment. Authentication is performed by the LDAP server, and authorization is handled by the OMi server.

You can configure the LDAP server for authentication and automatic user creation by using the LDAP Configuration panel. For details, see How to configure LDAP authentication.

For information on setting up multiple LDAP connections, see Multi-LDAP authentication and How to set up Multi-LDAP.

For information on securing communication between an LDAP server and your OMi server over TLS, see How to secure communication between the LDAP server and OMi server over TLS.

LDAP setup workflows

The following section contains overviews of user management processes when LDAP is enabled, as performed by the OMi administrator and OMi itself when the user logs in.

When OMi users are authenticated with the LDAP server no passwords need to be stored on the OMi server or synchronized between different OMi servers.

OMi users marked as LDAP users can be created manually, and OMi users can be created automatically from LDAP users when the user logs into OMi for the first time.

OMi users can be automatically added to groups when a mapping between the LDAP groups and the OMi groups has been previously established. When the user logs in the first time, the LDAP group is used to configure OMi group membership. The user then automatically gets all permissions that are assigned to the OMi group.

LDAP user authentication, automatic user creation, automatic group mapping

• The OMi administrator uses the LDAP Configuration panel to configure an LDAP server. In addition the OMi administrator specifies LDAP Settings in Users, Groups, and Roles, where he enables automatic creation of users and maps OMi groups to LDAP groups.

• The OMi user logs on to OMi with their domain name and/or email address as the login name and their company password (defined in LDAP).

• The OMi server authenticates the user with the LDAP server, creates the user, and gets the group membership from the LDAP server and assigns the user to the corresponding OMi groups that have been mapped.

Note When setting up LDAP configurations in OMi, ensure that no local OMi user exists that has the same login name as the UUID attribute of an LDAP user, or the LDAP user will not be automatically created and will not be able to log in to OMi.

LDAP user authentication only (no user creation and no group mapping)

• The OMi administrator configures an LDAP server in the Authentication Management LDAP Configuration panel, and opens the LDAP Mapping Settings editor in Users, Groups, and Roles. The OMi administrator turns off automatic creation of users and automatic group assignment, switches to the user section of Users, Groups, and Roles, creates a new user with an email address as the login name (or any other unique LDAP ID that has been configured), and manually assigns roles to the user and places them in groups.

• The OMi user logs in to OMi with their domain name and/or email address as the login name and their company password (defined in LDAP).

• The OMi server authenticates the user against the LDAP server.

LDAP user authentication with automatic user creation (no group mapping)

• The OMi administrator uses the LDAP Configuration panel to configure an LDAP server, opens the LDAP Mapping Settings editor in Users, Groups, and Roles, and enables automatic creation of LDAP users.

• An OMi user logs in to OMi with their email address as the login name and their company password (defined in LDAP).

• The OMi server authenticates the user with the LDAP server and creates the user.

• The OMi administrator manually adds the LDAP user to groups, or selects the Add new users to group(s) option to add new users to defined groups.

Note When setting up LDAP configurations in OMi, ensure that no local OMi user exists that has the same login name as the UUID attribute of an LDAP user, or the LDAP user will not be automatically created and will not be able to log in to OMi.

Mixed mode authentication

• Mixed mode is enabled by default in the LDAP infrastructure settings.

• The OMi administrator configures an LDAP server, and enables automatic creation of users and synchronization of groups

• An OMi user logs in to OMi with a login name that does not exist in LDAP.

• The OMi server authenticates the user against the LDAP server.

Note Mixed mode authentication can be disabled for hardening purposes in the LDAP infrastructure settings, after connection to the LDAP server has been established.

Before disabling mixed mode authentication, administrators must create an LDAP user account in OMi with Super-admin permissions after enabling the LDAP server but before configuring group mapping and user synchronization that maps to a user on the LDAP server. Without an OMi account with Super-admin permissions, you cannot configure group mapping and user synchronization.

Multi-LDAP authentication

• When connecting to multiple LDAP servers, users do not have to be replicated on each server, as users logging into OMi as LDAP users use the domain, for example, EMEA/username, to log into OMi.

Note When creating LDAP users, logins must be unique across domains. For example, jane.doe@americas.com and jane.doe1@emea.com.

The OMi administrator manually adds the LDAP user to groups, or selects the Add new users to group(s) option to add new users to defined groups.

Synchronizing users

Granting roles

It is recommended to grant roles at the group level in OMi, and then to nest users into groups according to their desired permission level. For information about group hierarchy, see Groups and Group Hierarchy. For information about roles and permissions, see Roles and Permissions.

If users are moved between LDAP groups mapped to OMi groups, they are moved between their corresponding mapped groups on the OMi server after logging into OMi.

Status of LDAP users not in OMi

LDAP users who do not yet exist in OMi, are created as OMi users. Their status is determined as follows:

• If the users belong to a mapped LDAP group, they are automatically assigned to the OMi group that is mapped to their LDAP group, as set in Users, Groups, and Roles and in the LDAP Mapping Settings editor.

• If their group is not mapped to an OMi group, or if they do not belong to an LDAP group, they are created as an OMi user with no group memberships. You can specify in which OMi group users are placed in the LDAP Mapping Settings editor in the LDAP pane of the Users, Groups, and Roles page. For information, see How to map groups and synchronize users.

Matching the users filter

To log into OMi, an LDAP user must match the criteria defined in the Filter from the Advanced subsection of the LDAP Configuration panel. For more details, see How to configure LDAP authentication.

Any new LDAP user who satisfies the user filter will be created as an OMi user on first login. Ask your LDAP administrator to help you narrow down the filter definition so that only appropriate users can gain access to OMi.

Obsolete users

Users that have been removed from the LDAP server are still displayed as OMi users, even though they are no longer registered as LDAP users and cannot log into OMi.

Mapping groups

You set group mappings in the groups editor of Users, Groups, and Roles, and enable group synchronization in the LDAP Mapping Settings editor, to enable user synchronization between LDAP users and OMi users. The group mapping feature is accessible through the Users, Groups, and Roles page by clicking LDAP Mapping Settings on the LDAP pane. The LDAP pane is available if an LDAP configuration has been set up and is enabled.

Caution When an LDAP configuration is edited by changing the LDAP host name, group mappings also reflect this name change. However, if the LDAP group that is configured to map to an OMi group does not exist on the new LDAP host, the group mapping must be adjusted manually.

For task information, see How to map groups and synchronize users.

For information on configuring LDAP, see How to configure LDAP authentication.

OMi supports user authentication using smart cards. If smart card authentication is configured, you cannot log in without a valid smart card.

For more information on Smart Card Authentication, see Configure Client Certificate or Smart Card Authentication.

This information helps you to create an SSO authentication strategy for logging into OMi. Follow these steps:

1. In the Single Sign-On Configuration area on the left, click Edit to open Single Sign On Editor panel.

   This panel enables you to configure a Single Sign On strategy. The elements displayed in the Single Sign On Editor panel are determined by the Single Sign On mode you choose.

2. Choose the desired mode from the following SSO authentication modes:

   • Not Configured

     Default selection. This means that SSO authentication is disabled.

   • IdentityManagement

     Select to configure the Identity Management Single Sign-On (IDM-SSO) authentication strategy. For details on the elements displayed in this page, see the Step 3. For details on this SSO authentication strategy, see Identity Management Single Sign-On authentication.

     If you have selected this option, LDAP can be configured only for group mapping and not for authentication.

   • Lightweight

     Select to configure the Lightweight Single Sign-On (LW-SSO) authentication strategy. For details on the elements displayed in this page, see below. For details on this SSO authentication strategy, see Lightweight Single Sign-On authentication.

3. If you have chosen the Identity Management SSO mode, fill appropriately the following fields in the Identity Management Single Sign-On Configuration section:

   • HTTP header name:

     Enter the HTTP header name for the token name passed by the Identity Management Single Sign-On (for example, sso_user).

     Ensure that the Identity Management Single Sign-On strategy is securing OMi resources before you enter this information.

   • Logout url:

     Optional. Enter an alternate logout URL, to view a page other than the main login page when logging out of OMi (for example, \<alternativeLogoutURL>.jsp).

4. If you have chosen the Lightweight SSO mode, fill appropriately the following fields in the Lightweight Single Sign-On Configuration section:

   • Token Creation Key (initString):

     Enter an initString value that is used for encryption and decryption of the LW-SSO token. If you change this value, remember to set initString to the same value in all HPE products participating in LW-SSO integration.

     Note If you are running OMi in a containerized version of the Operations Bridge Suite, the Token Creation Key (initString) can only be edited in the management portal. For more information, see the Operations Bridge Suite Help.

   • HPE Operations Manager i Domain:

     Enter the relevant OMi domain, to be used for token creation. The Domain field may be required for multi-domain support and normalized URLs when the domain cannot be parsed automatically (for example, when using aliases). To add a host or a domain to the list of trusted hosts/domains, click Add a trusted host/domain button.

   • Trusted Hosts/Domains

     Displays a list of trusted hosts and domains that are participating in an LW-SSO integration.

     The list of trusted hosts can contain DNS domain name (myDomain.com), NetBIOS name (myServer), IP address, or fully qualified domain name (FQDN) for the specific server (myServer.myDomain).

     Enter the name of the host or domain and select the type of host or domain name from the drop-down box. Confirm your choice by clicking .

     To edit a host or a domain from the list of trusted hosts/domains, click Edit in the right corner of the row that represents this host or domain. To Applyremove a host or a domain, click Delete.

5. To enable authentication by using the Security Assertion Markup Language 2.0 protocol, select Enable SAML2 authentication schema check box.

   If you select the Enable SAML2 authentication schema check box, the SAML2 Creation and SAML2 Validation sections are displayed.

6. In the SAML2 Creation: section, modify the SAML2 Authentication parameters for sending SAML authentication requests from OMi. Set the following:

   • Look for keystore in classpath

     Select for the Lightweight Single Sign-On framework to search for the keystore in the classpath.

   • Keystore filename:

     This field is visible only when the Look for keystore in classpath check box is selected. Its value must be the file name of the keystore (for example: java.keystore.).

   • Keystore path/location

     This field is visible only when the Look for keystore in classpath check box is cleared. Its value must be the full path of the keystore's location in OMi (for example: C:\mystore\java.keystore.).

   • Keystore password:

     The password that enables access to the keystore containing the private key used for encryption during the SAML authentication request.

   • Private key alias:

     Indicates the alias of the private key used for encryption during the SAML authentication request.

   • Private key password:

     Indicates the password of the private key used for encryption during the SAML authentication request.

7. In the SAML2 Validation: section, modify the SAML2 authentication parameters for decrypting SAML requests received by OMi. Set the following:

   • Look for keystore in classpath

     Select for the Lightweight Single Sign-on framework to search for the keystore in the classpath.

   • Keystore filename:

     This field is visible only when the Look for keystore in classpath check box is selected. Its value must be the file name of the keystore (for example: java.keystore.).

   • Keystore path/location:

     This field is visible only when the Look for keystore in classpath check box is cleared. Its value must be the full path of the keystore's location (for example: C:\mystore\java.keystore.).

   • Keystore password:

     The password of the public key used for decryption during the SAML authentication request.

8. Click Save to save your preferences.

This information enables you to create an LDAP authentication strategy for logging into OMi. Follow these steps:

1. In the LDAP Configuration area on the left, click New to open a new LDAP Configuration panel, or Edit to modify the existing LDAP authentication strategy.

   Note For OMi deployments in an Operations Bridge Suite container, LDAP connections must be configured in the management portal. The LDAP configuration option will not be displayed in the OMi interface. For more information, see the Operations Bridge Suite Help.

2. In the General Configuration section you can use an external LDAP server to store authentication information (user names and passwords) and to enable user synchronization between LDAP users and OMi users. Set the following:

   • Unique domain:

     The unique domain field lets you specify the LDAP domain used to log into OMi by using the following format: <unique-domain>\<username>.

     For example, if you specify emea, users will be able to log into OMi in the format emea\janedoe. Alternatively, users can log in by using the mail address format (for example, jane.doe@example.com). In the case of email addresses, the domain suffix (example.com) must be chosen as the unique domain name, and the appropriate UUID attribute must be chosen in the Advanced subsection.

     Note  

     • If you want to use multiple LDAP servers, or if you want to use LDAP users with command-line utilities such as RestWsUtil, you must specify mail address format logins.

       For information on the RestWsUtil command-line utility, see RestWsUtil Command-Line Interface.

     • If only one LDAP configuration is present, the domain of this LDAP configuration is considered as the default domain. Users can log in by using their LDAP login name only, without having to specify a domain.

   • LDAP server url:

     Enter the URL of the LDAP or, for Active Directory users, Global Catalog [AD GC] server.

     Enter multiple DNs, separated by semicolons.

     To allow failover, enter multiple LDAP (AD GC) server URLs, separated by semicolons.

     The required format is ldap://machine_name:port/scope??sub.

     • LDAP servers typically use port 389 or secure port 636, whereas AD GC servers typically use port 3268 or secure port 3269.

     • Possible values of scope = sub, one, or base, and are case sensitive.

     • OMi ignores the attribute between the two question marks, if one exists.

     • When the port number and scope value are empty, default values are used.

     • Default port number for regular communication: 389

     • Default port number for TLS communication: 636

     • Default scope value: sub

     Note The scope does not work when the containers of users are groups, because groups become members of the base group. The resulting behavior is equivalent to selecting a sub scope:

     • The base scope does not retrieve any users inside the container.
     • The one scope retrieves all users below the base container and not the users that belong to groups inside the base container.

     Examples:

     Single DN, single LDAP server: ldap://my.ldap.server:389/ou=People,o=myOrg.com??sub

     You can configure multiple domains by entering LDAP server URLs separated by a semicolon (;). The server names must be the same in order to search users in both LDAP servers.
     

     Multiple DNs: ldap://my.ldap.server:389/ou=People,o=myOrg.com??sub;
ldap://my.ldap.server:389/ou=Staff,o=my2ndOrg.net??sub

     You can configure failover by entering different LDAP server URLs separated by a semicolon (;). For failover, the domain names must be the same.

     Failover LDAP servers: ldap://my.ldap.server:389/ou=People,o=myOrg.com??sub;
ldap://my.2ndldap.server:389/ou=People,o=myOrg.com??sub

     If you receive a red X after entering the URL with the following pop-up text: 
     ERROR - sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target,
     you must establish trust to the LDAP server.

     The server names must be the same in order to search users in both LDAP servers.

   • Vendor type:

     Enter the LDAP vendor that you are using. Select among the following:

     • Common LDAP

     • Customized

     • Microsoft Active Directory

   • Advanced

     In this section you can modify the default LDAP settings that are specific to the selected vendor.

     Note If you modify the LDAP vendor attribute settings in this subsection, the value of the Vendor type field in the General Configuration section automatically changes to Customized.

     In addition to name/surname and display name attributes that can be set in each part of this subsection, there are the following attributes available:

     • User part:

       • UUID attribute:

         The attribute you want to use to log in to OMi with, as it appears on the LDAP server.

       • Filter:

         Defines which LDAP users have permission to log in to OMi.

       • Object class:

         Defines which LDAP entities will be considered users on the LDAP server.

       • Mail attribute:

         User's email address.

     • Group part:

       • Class object:

         Defines which LDAP entities are to be considered groups on the LDAP server.

       • Description attribute:

         Description of the LDAP group's entities.

       • Member attribute:

         Defines the specific attribute that determines which of the LDAP group's entities will be considered members of the LDAP group.

         Caution LDAP posixGroup objects are not supported. Use a group object that lists the Distinguished Name (DN) of its members (for example groupOfNames).

     • Dynamic Group part:

       • Class:

         Defines which LDAP entities will be considered dynamic groups on the LDAP server.

       • Member attribute:

         Defines the specific attribute that determines which of the LDAP dynamic group's entities will be considered members of the LDAP dynamic group.

       • Description attribute:

         Description of the LDAP dynamic group's entities.

   • DN:

     Select the Distinguished name resolution check box to enable entering LDAP search user credentials. If your LDAP requires user credentials to verify a connection to an LDAP server, use the LDAP Configuration panel or the users-remote-repository service in the JMX console to enter these credentials. Valid user credentials are required to continue using LDAP server URL.

   • Search entitled user:

     This field is visible only when the Distinguished name resolution check box is selected. It defines the Distinguished Name (DN) of a user with search privileges on the LDAP directory server.

     Leave this entry blank for an anonymous user.

   • User password:

     This field is visible only when the Distinguished name resolution check box is selected. It defines the password of the user entitled to search the LDAP server entities for groups.

     Leave this entry blank for an anonymous user.

   • Test resolution:

     Enables you to verify that both the configured LDAP parameters and the credentials of a specified user are valid. The following fields are available:

     • UUID

       The actual login name (Unique User ID) of the LDAP user you want to verify.

     • Password

       Optional. The password of the user whose credentials are entered in the UUID field. This field is optional. If you leave it empty, an anonymous user is used.

     Click Test to test the LDAP configuration and user credentials validity. A message is displayed indicating whether or not the validation was successful.

3. In the Group Mapping Configuration section, configure the LDAP server to synchronize LDAP users with OMi users. Set the following:

   • Group base DN:

     The Distinguished Name (DN) of the LDAP entity from which you want to start your group search.

     You can configure multiple domains by entering domains separated by a semicolon (;).
     

   • Group search filter:

     Enter the relevant parameters to indicate which attributes will be included in the group search.

   • Root group base DN:

     The Distinguished Name (DN) of the LDAP groups that will be first on the hierarchical tree of mapped groups. This value must be a subset of the Groups base DN.

   • Root group filter:

     Enter the parameters to determine which LDAP entities are to be the hierarchical base for the LDAP groups. The specified entities can later be mapped to groups in OMi.

   • Test groups:

     Verifies that the parameters entered to define the LDAP groups structure are valid, and displays all groups that match the configuration. If the result includes more than 1000 groups, only the first 1000 groups are displayed.

4. Click Create when creating a new LDAP authentication strategy. If you have modified the existing strategy, click Save to save your preferences. You can activate the strategy after saving by selecting the Activate after save check box.

This task describes how to modify options and parameters used with LW-SSO in the JMX console.

You can also use the JMX console if you are locked out of OMi and must change SSO parameters to gain access.

1. Enter the URL of the JMX console (https://localhost:29000) in a web browser.

2. Enter your JMX console authentication credentials. If you do not know your authentication credentials, contact your system administrator.

3. Locate the Lightweight Single Sign-On context, as follows:

1. Domain name: Topaz

2. Service: LW-SSO Configuration

4. Modify parameters accordingly.

The changes take effect immediately.

1. If you are using LDAP, ensure that the same user repository is used by OMi and the authentication point server.
   

   If you are not using LDAP, create the users manually in OMi.

2. Set the LW-SSO configuration file on the authentication point server side to use the same initString as in OMi.

   1. In a browser on the OMi gateway server, enter the URL of the JMX console:

      https://localhost:29000

   2. Enter your JMX console authentication credentials. The JMX Agent View appears.
   3. Under the domain name Topaz, click service=LW-SSO Configuration.

   4. Locate the AuthenticationPointServer attribute and enter the Authentication Point Server URL.

   5. Locate the ValidationPointEnabled attribute and set it to true.

   6. If you do not want particular URLs to use this feature, locate addNonsecureURL() and add the URLs to the list.

   7. Click Apply Changes.

3. Restart the OMi gateway server.

4. Make sure that you can log into OMi through the external authentication point. If you are unable to log in, see Unable to log into OMi when using an external authentication point.

This task describes how to modify the LDAP attribute with which you want to log into OMi.

1. In the LDAP Configuration area of the Authentication Management page, click Edit. The LDAP Configuration panel opens.

2. Click Advanced.

3. Modify the UUID attribute to the attribute you want to log in with, as it appears on the LDAP server.

1. If the LDAP server requires a secure connection perform the following steps:

   1. Obtain a root CA certificate from the Certificate Authority that issued the LDAP server certificate.

   2. Import it into the JRE truststore on each OMi gateway server.

      Example

      opr-cert-mgmt -import "myCA" "c:\RootCA.cer"

   3. Restart the OMi gateway servers.

2. Verify that communication between the LDAP server and the OMi server is valid over TLS by using the LDAP Configuration panel, as follows:

   1. Navigate to the Authentication Management page:

      Administration > Users > Authentication Management

      Click New to open the LDAP Configuration panel.

   2. Enter the URL of your LDAP server, according to the following syntax: ldaps://machine_name:port/<scope>??sub.

      Ensure that the protocol is ldaps://, and the port number is configured according to the TLS port, as configured on the LDAP server (default is 636).

   3. Select the Distinguished name resolution check box and enter the UUID and password of a known LDAP user in the relevant fields.

   4. Test your configuration by clicking Test to authenticate the user. For details, see How to configure LDAP authentication.

1. Configure group filters on the LDAP Server for mapping groups. You can configure group filters on the LDAP Server for mapping groups by using the LDAP Configuration panel. For task details, see How to configure LDAP authentication.

   Caution Before disabling mixed mode authentication, administrators must create an LDAP user account in OMi with Super-admin permissions after enabling the LDAP server but before configuring group mapping and user synchronization that maps to a user on the LDAP server. Without an OMi account with Super-admin permissions, you cannot configure group mapping and user synchronization.

   Go to Administration > Users > Users, Groups, and Roles.

2. Create OMi groups and group hierarchies. For detailed information, see Groups and Group Hierarchy.

3. Map LDAP groups to OMi groups in Users, Groups, and Roles.

   You can enable group mapping synchronization in the LDAP Mapping Settings editor.

   In addition to enabling the setting in the LDAP Mapping Settings editor the OMi administrator must map the OMi group to one or more LDAP groups. This is done in the Group editor in Users, Groups and Roles by navigating to a group and editing the Mapped LDAP groups field.

   You can enable synchronization of user groups on the LDAP server with user groups in OMi by selecting the Automatically create LDAP users check box in the LDAP Mapping Settings editor.

4. Enable user synchronization

   Select Automatically create LDAP users in the LDAP Mapping Settings editor to enable automatic user creation upon logging into OMi to create LDAP users in OMi.

1. Open Users, Groups, and Roles:

   Administration > Users > Users, Groups, and Roles.

2. Click Manage Groups and select the group you want to edit or create a new group.

3. In the Properties section of the selected group, search for and assign LDAP groups in the Mapped LDAP groups field as required and save the group.

Important information

1. Prerequisite. LDAP must be configured in Authentication Management for the LDAP pane to be available in Users, Groups, and Roles.

   You can configure LDAP either in Users, Groups, and Roles by clicking LDAP Connections, or in the Authentication Management page, by clicking New in the LDAP Configuration section.

2. Open Users, Groups, and Roles:

   Administration > Users > Users, Groups, and Roles

3. In the home page, click LDAP Mapping Settings on the LDAP pane.

• To synchronize LDAP groups with OMi groups, click Synchronize LDAP groups with OMi groups.

  To add users to specific OMi groups, select Automatically create LDAP users and then select Add new users to group(s). Start typing in the text box to add group previously created in OMi.

Setting up multiple LDAP configuration involves adding new configurations for each LDAP server you want OMi to connect to.

1. Navigate to the Authentication Management page:

   Administration > Users > Authentication Management

2. Click New to add another LDAP configuration.

3. Enter the LDAP server information following the steps described in How to configure LDAP authentication.

In a setup with multiple gateway servers, all gateway servers must be restarted after you change values in the LDAP configuration.

Make sure the correct header is used. Ask your IDM administrator to dump all headers and look for one that matches what you expect to use. For example, if you want to use an email address as your login username, look for a field containing only an email address. Or, for example, if it looks like HTTP_SEA, remove HTTP_ from the name and use sea as the header name.

To verify that you get the correct user ID with the header you provided, go to https://<gateway server>/topaz/verifyIDM.jsp?headerName=sea (if sea is your header).

If you are locked out of OMi, you can update selected Lightweight Single Sign-On (LW-SSO) parameters remotely using the JMX console on the application server that is embedded in OMi.

For details on how to change LW-SSO parameters outside the OMi interface, see How to modify LW-SSO parameters by using the JMX console.

LW-SSO does not ensure user synchronization between integrated applications. Therefore, you must enable LDAP and configure group mapping for the integrated application to monitor users. Failure to map groups and synchronize users may cause security breaches and negative application behavior. For details on mapping users between applications, see LDAP authentication.

The LW-SSO security context supports only one attribute value per attribute name.

Therefore, when the SAML2 token sends more than one value for the same attribute name, only one value is accepted by the LW-SSO framework.

Similarly, if the IdM token is configured to send more than one value for the same attribute name, only one value is accepted by the LW-SSO framework.

If you enabled an external authentication point (AP) and are unable to log in through it, make sure that the user whose credentials you are entering is defined as a user in OMi.

If the OMi login page appears after entering a valid client certificate, test the following:

• Try to log in using the User Identifier (often email address).
  If you can log in, make sure that the LDAP user filter was configured to use the same user identifier.

• If the Login page still appears and you are using the Apache web server, add the following to <OMi gateway installation directory>/Webserver/conf/extra/httpd-ssl.conf under #SSLOptions:
  SSLOptions +ExportCertData.

If your LDAP or SSO settings have not been configured properly, you may not be able to access OMi. If this happens, reset your LDAP or SSO settings remotely by using the JMX console.

1. In the JMX Agent View, under the domain name Topaz, click service=SSO.
2. Locate the void setSingleSignOnMode() attribute and set it to Disabled.

If LDAP is configured and you are unable to login:

1. In the JMX Agent View, under the domain name Foundations, click service=users-remote-repository.
2. Locate the RemoteUserRepositoryMode attribute and set it to Disabled.

When setting the LDAP server URL, you see a red cross containing the following error:

ERROR - sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

This means that you have not yet configured a secure connection to the LDAP server.

For details about securing a connection to the LDAP server, see How to secure communication between the LDAP server and OMi server over TLS.

With the multi-LDAP feature, HPE recommends providing a domain name at login. If you use the <username>@<domain> style, make sure <domain> is the unique domain specified in your LDAP configuration.

You can also use the <domain>/<username> style. In this case you can provide, for example, sAMAccountName as the UUID attribute, and HP1 as the unique domain attribute. Users would then be able to log in with HP1/<sAMAccountName>. The HP1/<username> format will work in an LDAP configuration with HP1 as the unique domain and sAMAccountName as the UUID attribute, provided that <username> is stored in this attribute on the LDAP server.

Note that the unique domain attribute can be an arbitrary string, and does not have to match the full domain name of your organization.

If you need a default group mapping for all users who do not fit into any of the currently mapped groups, request that your corporate LDAP server administrator create a dynamic LDAP group based on the same user filter that you specified in the OMi LDAP configuration.

This user filter automatically populates and maintains members of the dynamic group in your corporate LDAP.

In OMi, create a local group with the roles and permissions that you require by default. Map the dynamic group created in your corporate LDAP to the OMi local group. Any user who is allowed to enter OMi but does not belong to any other mapped group will belong to the default group. Without such a default group, these users would be created at the root level in the User Management tree and their permissions would need to be handled individually.

To enable dynamic LDAP groups in OMi, go to Administration > Setup and Maintenance > Infrastructure Settings, select the LDAP Configuration context from the Foundations drop-down list and set Enable dynamic groups to true. The change takes effect immediately.

Note the following limitations when working with LW-SSO authentication:

• Client access to the application.

  If a domain is defined in the LW-SSO configuration:

  • The application clients must access the application with a Fully Qualified Domain Name (FQDN) in the login URL, for example, http://myserver.companydomain.com/WebApp.

  • LW-SSO cannot support URLs with an IP address, for example, http://192.168.12.13/WebApp.

  • LW-SSO cannot support URLs without a domain, for example, http://myserver/WebApp.

  If a domain is not defined in the LW-SSO configuration: The client can access the application without a FQDN in the login URL. In this case, an LW-SSO session cookie is created specifically for a single machine without any domain information. Therefore, the cookie is not delegated by the browser to another, and does not pass to other computers located in the same DNS domain. This means that LW-SSO does not work in the same domain.

• LW-SSO framework integration. Applications can leverage and use LW-SSO capabilities only if integrated within the LW-SSO framework in advance.

• Multi-Domain Support.

  • Multi-domain functionality is based on the HTTP referrer. Therefore, LW-SSO supports links from one application to another and does not support typing a URL into a browser window, except when both applications are in the same domain.

  • The first cross domain link using HTTP POST is not supported.

    Multi domain functionality does not support the first HTTP POST request to a second application (only the HTTP GET request is supported). For example, if your application has an HTTP link to a second application, an HTTP GET request is supported, but an HTTP FORM request is not supported. All requests after the first can be either HTTP POST or HTTP GET.

  • LW-SSO Token size:

    The size of information that LW-SSO can transfer from one application in one domain to another application in another domain is limited to 15 Groups/Roles/Attributes (note that each item may be an average of 15 characters long).

  • Linking from Protected (HTTPS) to non-protected (HTTP) in a multi-domain scenario:

    Multi domain functionality does not work when linking from a protected (HTTPS) to a non-protected (HTTP) page. This is a browser limitation where the referrer header is not sent when linking from a protected to a non-protected resource.

• SAML2 token.

  • Logout functionality is not supported when the SAML2 token is used.

  Therefore, if the SAML2 token is used to access a second application, a user who logs out of the first application is not logged out of the second application.

  • The SAML2 token's expiration is not reflected in the application's session management.

  Therefore, if the SAML2 token is used to access a second application, each application's session management is handled independently.

• JAAS Realm. The JAAS Realm in Tomcat is not supported.

• Using spaces in Tomcat directories. Using spaces in Tomcat directories is not supported.

  It is not possible to use LW-SSO when a Tomcat installation path (folders) includes spaces (for example, Program Files) and the LW-SSO configuration file is located in the common\classes Tomcat folder.

• Load balancer configuration. A load balancer deployed with LW-SSO must be configured to use sticky sessions.

The following are security warnings that are relevant to the LW-SSO configuration:

• Confidential InitString parameter in LW-SSO. LW-SSO uses Symmetric Encryption to validate and create a LW-SSO token. The initString parameter within the configuration is used for initialization of the secret key. An application creates a token, and each application using the same initString parameter validates the token.

  Caution  

  • It is not possible to use LW-SSO without setting the initString parameter.

  • The initString parameter is confidential information and should be treated as such in terms of publishing, transporting, and persistency.

  • The initString parameter should be shared only between applications integrating with each other using LW-SSO.

  • The initString parameter should have a minimum length of 12 characters.

• Level of authentication security. The application that uses the weakest authentication framework and issues a LW-SSO token that is trusted by other integrated applications determines the level of authentication security for all the applications.

It is recommended that only applications using strong and secure authentication frameworks issue an LW-SSO token.

• Symmetric encryption implications. LW-SSO uses symmetric cryptography for issuing and validating LW-SSO tokens. Therefore, any application using LW-SSO can issue a token to be trusted by all other applications sharing the same initString parameter. This potential risk is relevant when an application sharing an initString either resides on, or is accessible from, an untrusted location.

• User mapping (Synchronization). The LW-SSO framework does not ensure user mapping between the integrated applications. Therefore, the integrated application must monitor user mapping. HPE recommends that you share the same user registry (as LDAP/AD) among all integrated applications.

  Failure to map users may cause security breaches and negative application behavior. For example, the same user name may be assigned to different real users in the various applications.

  In addition, in cases where a user logs onto an application (AppA) and then accesses a second application (AppB) that uses container or application authentication, the failure to map the user will force the user to manually log on to AppB and enter a user name. If the user enters a different user name than was used to log on to AppA, the following behavior can arise: If the user subsequently accesses a third application (AppC) from AppA or AppB, then they will access it using the user names that were used to log on to AppA or AppB respectively.

• Identity Manager. Used for authentication purposes, all unprotected resources in the Identity Manager must be configured with the nonsecureURLs setting in the LW-SSO configuration file.