Using Helix ALM and Surround SCM electronic signatures with identity providers
If your organization uses Helix ALM or Surround SCM electronic signatures and users are configured to authenticate using an identity provider, it is important to make sure the provider is configured correctly. If the provider is configured incorrectly, electronic signatures are invalid, which can lead to non-compliance issues. See the Helix ALM and Surround SCM help for information about electronic signatures.
Requirements
To ensure valid electronic signatures, the identity provider must support forced reauthentication, specifically:
- For providers that support OpenID Connect, the identity provider must respect the max_age request parameter.
- For providers that support SAML, the identity provider must respect the forceAuthn request parameter.
When an electronic signature is required, Helix ALM or Surround SCM tells the identity provider to reauthenticate the user. Most identity providers support single sign-on, which remembers that the user already authenticated, so the provider does not reprompt for authentication credentials. The forced reauthentication parameter tells the iprovider to always ask for authentication credentials when a request is received, regardless if the user recently authenticated. If the SAML or OpenID Connect identity provider does not support this part of the standard, the provider could incorrectly return a successful login status without actually prompting for authentication credentials.
Recommendations
We recommend requiring two signature components for Helix ALM and Surround SCM electronic signatures. Selecting this option hides the username value in the Helix ALM or Surround SCM status bar, which helps avoid security risks. See the Helix ALM and Surround SCM help for information about setting signature component options.
How it works
The following steps explain the process for entering an electronic signature for a user who authenticates with an identity provider.
1. The user makes a change that requires an electronic signature in Helix ALM or Surround SCM.
The Signature Required dialog box opens. The Username and Password fields are not displayed. A Reason field may be displayed.
2. The user clicks OK in the Signature Required dialog box. The identity provider page opens in a browser.
3. The user authenticates on the provider page.
4. If authentication is successful, the user returns to Helix ALM or Surround SCM.
Testing for valid electronic signatures
We recommend testing your identity provider and electronic signatures in Helix ALM and Surround SCM in your environment to make sure electronic signatures work and are valid.
1. Open a browser and log in to your identity provider. Do not close the browser at any point while testing.
2. Open Helix ALM or Surround SCM and log in. You likely will not be prompted for your credentials again because you already have a session with the identity provider in the browser.
3. Make a change that requires an electronic signature.
The Signature Required dialog box opens. The Username and Password fields are not displayed. A Reason field may be displayed.
4. Click OK in the Signature Required dialog box. The identity provider page opens in a browser. If the provider page does not require you to authenticate, the provider is not forcing reauthentication and the electronic signature is invalid.
5. Authenticate on the provider page.
6. If authentication is successful, return to Helix ALM or Surround SCM.
Failed authentication attempts
Failed authentication attempts in the identity provider that are logged to the license server indicate that the license server timed out when waiting for the provider to return a successful login. If the user attempts to authenticate in the provider multiple times within 60 seconds, the identity provider only returns one failure status after 60 seconds and the license server only logs one failed login attempt. If the user leaves their computer without authenticating with the provider, the license server gets the same return status of a failed login attempt. The number of failed login attempts is used when locking out users for failed login attempts based on the Lock user after failed login server option. See Setting authentication options.
