Managing Operators

FlexNet Manager Suite 2020 R1 (On-Premises)

There are two main aspects of managing operators:

1. Creating credentials (or identities) for the operators in both FlexNet Manager Suite and your current identity provider.
2. Assigning each operator to the appropriate role. In FlexNet Manager Suite, access and privileges are controlled by the Role(s) assigned to an operator. Without a role, an operator cannot view any pages of FlexNet Manager Suite, even though a valid identity may be used. Role assignment can only be performed by an administrator (that is, an operator who is already assigned to the Administrator role).

Another minor point may be to manage the expectations of operators if your enterprise is using Google OAuth and you modify the Timeout period setting in the Security tab of the System Settings page.

Creating an operator

Operator identities may be created manually. You may create the identity first in your SAML-compliant tool, after which there are two ways you can create the matching identity within FlexNet Manager Suite:

1. As an existing administrator in FlexNet Manager Suite, you can create the local account manually. In the Account field on the Create an Account page in FlexNet Manager Suite, enter the operator's email address. (This differs from the use of Windows Authentication, where you can select the account name from a drop-down list, imported from Active Directory.)
   • If you are using Flexera Account Management, this is the value that the operator uses to log in.
   • If you are using a SAML-compliant single sign-on identity provider (such as Okta), this is the account identity that is passed from your identity provider to FlexNet Manager Suite (the service provider) in the identity assertion. This is independent of the user name with which the operator logs into the identity provider.
   For more information, see the online help for the Create an Account page.
   Tip: If you are migrating from Integrated Windows Authentication, the existing operator accounts using that method are very unlikely to be useful when you switch to SAML authentication, because they rely on the domain/user name within Active Directory. This is most unlikely to be the account identifier in your SAML tool. Therefore you need to create new operator accounts, using the SAML account identifier (frequently this is an email address, or perhaps an employee number).
2. You may allow the operator account within FlexNet Manager Suite to be created automatically on the first attempt to log in with an identity registered in the single sign-on solution. This happens when the createUnknownOperator setting has its default true setting (see Configuring FlexNet Manager Suite as a SAML Service Provider).
   Important: While the local account is automatically created, no roles are assigned to it. As a result, the operator receives a Sign In Failure message on this first login attempt (a secure outcome). To permit access, an administrator needs to add the appropriate role(s) for each new operator. For this reason, if you as administrator want to use this labor-saving approach, it is best done in collaboration with each of the new operators, so that they are not confused by the deliberate failure that, for security reasons, persists until roles are assigned.

Ensuring administrator access

We have seen that operators must be assigned to roles before having access to FlexNet Manager Suite; and we have also noted that role assignment can only be performed by an administrator. When you are using your SAML-compliant, single sign-on solution, this could produce a chicken-and-egg situation, where no one can log in to make anyone an administrator.

The solution is that an administrator account (an operator who is assigned to the Administrator role) can be automatically created by an assertion from the SAML identity provider. The Administrator role is the only role that can be automatically assigned as a result of assertion by the identity provider.

To create an administrator automatically, arrange for your identity provider to include, in the appropriate identity assertion, a custom property called FnmsAdmin. This custom assertion needs to return a Boolean value (either true or false) to indicate whether the user is to be assigned to the Administrator role in FlexNet Manager Suite.

You may be able to set this property manually (for each identity), or programmatically. For example, your identity provider may support creating a group for all identities which are to have administrator properties. You may then be able to test whether the current identity is a member of that group, in order to return the true or false Boolean result. For example, when using the identity provider Okta, the values used are:

Name

FnmsAdmin

Name format (optional)

Basic

Value

isMemberOfGroupName("Administrators")

Tip: Function name is case-sensitive.

Once the FnmsAdmin property is configured in your identity provider, it is passed to FlexNet Manager Suite, including on the first login attempt for a new identity. As seen in the previous section above, the first login attempt with the new identity creates the matching local account in FlexNet Manager Suite. When the assertion says FnmsAdmin is true, the assignment to the Administrator role is made automatically, and the initial login attempt succeeds. (Contrast this with previous comments, that non-administrator operators see a sign in failure until they have been assigned to one or more roles.)

Note: In the account properties for this operator, the Role is set to Administrator, and because of the way this was asserted, it cannot be removed. If you wish to remove the administrator permission, you must first change the setting from the identity provider, and thereafter update the role assignment within FlexNet Manager Suite.

Impact of session timeout

The session timeout setting (Timeout period on the Security tab of the System Settings page) only affects those operators who either:

• Log in using Google OAuth identities
• Log in using a SAML-2.0-compliant single sign-on solution (such as Okta), but that identity provider does not return the optional SessionNotOnOrAfter attribute within its assertion (that is, the identity provider does not return any timeout information).

When an operator first logs in, the identity provider usually sends information about the projected session expiry as part of its identity assertion for the authorized operator (and when the identity provider does do this, the value it provides controls the expiry, and the Timeout period value in the web interface is ignored).

Whether set by FlexNet Manager Suite (through your web interface settings) or by the identity provider, the timeout countdown is recorded in a cookie in the operator's browser, and a non-zero countdown is refreshed after each action that interacts with the central application server (that is, the timeout restarts after each relevant action, such as saving data, moving to a new page, or searching). If the operator "goes quiet" and the countdown expires, the next attempt at any relevant activity causes FlexNet Manager Suite to request a new authorization from the identity provider. This means, of course, that the login screen reappears when, after a 'quiet time', the operator attempts some relevant action in the web interface for FlexNet Manager Suite. To minimize disruption, after logging in again, the operator is returned to the page they were looking at when the timeout occurred.

Tip: Configuration of your SAML-compliant identity provider may include setting SAML Offset Minutes to allow for clock variations between the identity provider and the service provider. Typically this value is set for 5 minutes, and this is added to the session expiry time. This means that if you choose a Timeout period of (say) 30 minutes, the session expires only after 35 minutes of inactivity.