Micro Focus Operations Orchestration security overview and best practices

Micro Focus Frequent Contributor
Micro Focus Frequent Contributor
2 0 774

The IT process automation capabilities of Micro Focus Operations Orchestration helps automate end-to-end IT processes across ITOM suites. The software enables IaaS, PaaS, and XaaS (anything-as-a-service) with comprehensive OOB operations and workflows for operating systems, databases, middleware and more. Let’s take a look at an overview of security features and the associated best practices in Micro Focus Operations Orchestration Software.

Security Overview

Authentication

Micro Focus Operations Orchestration 10.80 (OO) software can use any of the following authentication mechanism types:

  1. OO Internal Users: Users and their passwords are created and maintained internally within OO. OO uses its internal database for authentication and authorization data.
  2. Lightweight Directory Access Protocol (LDAP): Users are created and maintained in an external LDAP Application. OO connects to LDAP for user authentication and authorization data.
  3. Security Assertion Markup Language (SAML): OO connects to a SAML identity provider for exchanging authentication and authorization data.
  4. Identity Manager (IDM): When a user logs on to OO Central, OO redirects that user to an IDM login page. The user is redirected back to OO Central after a successful login. IDM can be used with LDAP to exchange authentication and authorization data.
  5. Client Certificate: Client certificate provides additional layer of security for “OO internal users” and “LDAP authentication” mechanism types. A client certificate maps to an internal OO user or to a LDAP user, which in turn controls authentication and authorization. OO Central Server asks for a client certificate when a client submits a login request. If that client certificate is in the list of trusted client certificates, then OO authenticates that client for login.
  6. Lightweight Single Sign-On (LWSSO): LWSSO is a solution that enables single sign on using a single common authentication among multiple Micro Focus products. LWSSO is not enabled out of the box. LWSSO works when MF products participate in LWSSO and user’s login ID matches across MF products. When a user authenticates successfully with one of the Micro Focus products using a web client, LWSSO creates a cookie. When the same user tries to access second MF application using the same web client in the same session, LWSSO shares that cookie with the second MF application. Second MF application allows that user to login without prompting for credentials. When OO allows user authentication based on LWSSO, authorization data is derived based on either OO internal users and roles or LDAP/SAML groups and roles.

 

IDM and LWSSO mode of authentication mechanisms cannot co-exist. If OO is configured to use LWSSO, IDM cannot be used at the same time. If OO is configured to use IDM, LWSSO cannot be used at the same time.

Authorization

Once a user is authenticated, OO uses “Role-based access control” to manage the authorization of a logged-on user.  The ability to run an OO flow or to view an OO flow is granted to roles on individual OO flows.

A role is a collection of permissions that can be granted to a set of users or to a set of user groups. Roles are stored and maintained within OO. When users are created and managed within OO, a user is assigned to one or more roles. When users are created and managed in an LDAP/SAML/IDM, a user’s LDAP/SAML/IDM groups are assigned one or more roles in OO.

When authentication is performed using LDAP/SAML, additional roles can be created. In LDAP/SAML mode, an administrator can map groups to existing out-of-the-box roles and newly created roles. When authentication is performed using IDM, additional roles cannot be created. In IDM mode, an administrator can only map groups to existing out of the box roles.

The following are different areas of permissions that can be included in a role definition:Permission Area.PNG

 Communication Channel Security

OO supports TLS protocol for communication between the OO Shell (OOSH) and OO Central, Browser and OO Central, OO Studio Remote Debugger and OO Central, OO Remote Action Service (RAS) and OO Central, Load Balancer and OO Central, LDAP and OO Central, IDM and OO Central, and SAML and OO Central. Operations Orchestration also supports Federal Information Processing Standards (FIPS) 140-2 Level 1 compliance. FIPS 140-2 is a standard for security requirements for cryptographic modules defined by the National Institute of Standards Technology (NIST).

Security Banner

The security banner displays a warning message to users logging on to OO. This warning message could be specific to your organization’s standard security warning message.

Audit

Audits help track actions such as user logins, triggering of OO flows, etc.

Password Encryption/Obfuscation

OO allows administrators to encrypt passwords that are stored in configuration files. OO allows flow authors to obfuscate passwords used in OO flows.

Session Timeout

OO can timeout an existing session which is open for a configured interval. Session timeouts prevent the unauthorized usage of an OO application if an end user leaves their system unlocked.

Signing of OO Content Packs

OO content packs contain intelligence to perform a given orchestration. Signing OO content packs with a certificate ensures integrity of OO content packs and protects content packs from tampering.

Security Best Practices

The following are some of the best practices in securing OO.

  • Secure OO Central using an SSL certificate. Out of the box, OO Central uses a self-signed server certificate. Consider replacing this self-signed server certificate with a certificate singed by a well-known certificate authority or based on your organization standards to generate a new certificate.
  • Consider enabling client certificate and/or FIPS 140-2 when mandated by regulatory requirements.
  • Secure communication channels between OO Central and other components/interfaces.
  • If a load balancer is used to access OO Central Servers, configure the load balancer for TLS offloading. This step allows for better utilization of the OO Central Servers.
  • Disable HTTP port connection to OO Central as HTTP protocol is not secure. This is used when not using load balancers that do TLS offloading. TLS offloading is recommended when using load balancers from performance considerations and as well as exposing a single certificate to clients.
  • Disable SSL 3.0 protocol as it has a security flaw that could allow an attacker to decrypt information such as authentication cookies. Using TLS 1.0, 1.1 or 1.2 provides security over SSL 3.0
  • Remove RC4, DES and Triple DES ciphers from SSL supported ciphers as multiple vulnerabilities have been discovered in these ciphers.
  • Change and encrypt KeyStore, TrustStore and Server Certificate passwords in OO Central. Out of the box, OO uses well known standard password of “changeit”. By changing this password, attackers would not be able to use standard password for malicious intentions.
  • Change and encrypt KeyStore and TrustStore passwords in OO Studio. Out of the box, OO uses well known standard password of “changeit”. By changing this password, attackers would not be able to use standard password for malicious intentions.
  • Enable “Authentication” in OO. Out of the box, OO does not require user id and password to login and will allow for unauthenticated access and flow execution.
  • Enable capture of logged-on user credentials which could be leveraged in OO flows to interact with other systems.
  • Connect OO to a secure LDAP Application or a SAML identity provider or IDM for authentication and authorization. Encrypt communication channel between OO Central and LDAP/SAML/IDM. OO internal authentication type should be used only when there are no other authentication types are available.
  • Maintain users and user groups in an LDAP/SAML/IDM as this allows for a central user maintenance and eliminates duplication and maintenance of user data in various applications.
  • Define LDAP/SAML/IDM user groups based on a characteristic that identifies a set of users that require similar privileges. For example, a job function or a business or a department.
  • Assign LDAP/SAML/IDM groups to any of the following out of the box OO roles: ADMINISTRATOR, END_USER, EVERYBODY, PROMOTER, and SYSTEM_ADMIN. If an out of the box OO role does not meet requirements, create a new OO role that correlates with LDAP/SAML user groups. Create a new role with minimal permissions. Extend permissions assigned to a role only when required. Assign newly created roles to corresponding LDAP/SAML user groups. In IDM mode, an administrator can only map groups to existing out of the box roles.
  • Majority of OO users should have either “END_USER” or “EVERYBODY” role. In an organization, there may be a small team who develop OO content packs, maintain and administer OO application. Apart from this small team, rest of the users are either “end users” of OO OR any other user/employee in an organization. End users such as Service Desk Agents, IT Analysts, etc. need minimal permissions to run a particular OO flow or view OO flow run details. These type of users should be assigned “END_USER” role. Multiple “END_USER” roles can be created to further restrict ability to run OO flows in different domains. The “EVERYBODY” role may be used as a default role so that users who do not have any roles assigned get access to OO with minimal privileges.
  • Very few users should have ADMINISTRATOR role. Users with “ADMINISTRATOR” role should have rights to all permission areas, “View OO flow” and “Run OO flow” for every OO flow.
  • Very few users should have “PROMOTER” role. Users with “PROMOTER” role should have rights to “content” permission area, “View OO flow” and “Run OO flow” for every OO flow.
  • Very few users should have “SYSTEM_ADMIN” role. Users with “SYSTEM_ADMIN” role should have rights to “system” permission area.
  • For each OO flow, assign “View OO flow” or “Run OO flow” privileges to appropriate roles. Out of the box, users with “ADMINISTRATOR” and “PROMOTER” roles are assigned “View OO flow” and “Run OO flow” privileges to every OO flow.
  • Sign custom OO content packs that are developed in-house at your organization. No action is necessary for Micro Focus OO content packs as they are shipped with digital signature.
  • Encrypt database login password using encrypt-password utility and update database.properties configuration file.
  • Passwords in OO flows should be obfuscated so that passwords are not visible in clear text in flow details.
  • Enable your security banner with a message that warns users about security rules that are specific to your organization. The security banner serves as a deterrent for unauthorized user logins.
  • By default, OO Central Web Interface session timeout is set to 30 minutes. Adjust session timeout based on your organization’s security requirements. Session timeouts prevent the unauthorized usage of an OO application if an end user leaves their system unlocked.
  • Enable audits to track actions such as user logins, OO flow triggers, etc.
  • Harden operating system, database, and tomcat applications based on respective vendor’s recommendation

References

Refer to the following documentation for more details related to setting up security in OO.

  1. OO 10.80 Administration Guide
  2. OO 10.80 Installation Guide
  3. OO 10.80 Use Guide

 

 

 

The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.