Security

• Auditing Report: Displays a report of all the administrative actions users have performed within Scrutinizer.

• Authentication: Configure general authentication settings, enable or disable different technologies, allow or deny users from different authentication methods and set the order in which methods are attempted.

• Authentication Tokens: These tokens can be used to automate Scrutinizer application logins with user-specific permissions and applicable expiration dates without having to include user name and passwords in the URL.

• LDAP Configuration: Server and connection settings for LDAP integration.

LDAP user authentication process

1. In the LDAP configuration, administrators provide credentials for an LDAP account with permission to see any users they’d like to permit access to.

1. This is the account that will be used to search for and authenticate users when they attempt to log in.

2. The searchbase defines the group that will be used to search for authorized users. This is a required field.

3. The scope of users in that searchbase who are allowed to authenticate can be limited in two ways:

• By specifying one or more Security Groups in the LDAP Configuration

• By specifying individual user account names in Security > Authentication > LDAP

2. To configure LDAP integration to use valid certificates, get a PEM encoded version of the Certificate Authority’s Certificate and place it into the /etc/pki/ca-trust/source/anchors/ directory. Provide the full path to the certificate in the “LDAP Server’s CA Certificate File” setting. Set the Certificate Verification to required.

3. A user attempts to log in. The system authenticates as the administrative account provided, then checks a searchbase specified by the Scrutinizer administrator for any account matching the username provided. Authentication with the sAMAccountName, UserPrincipalName, or uid attribute is supported.

4. If the LDAP server responds with an LDAP_REFERRAL code, Scrutinizer will check the referred server.

5. If the Scrutinizer administrator has specified multiple LDAP servers, it will check them all until successfully authentication succeeds or fails.

6. Once the user has successfully authenticated for the first time, Scrutinizer checks for any security group they’re a member of which also exists in Scrutinizer with the same usergroup name. If it does, they’re added to the Scrutinizer usergroup automatically.

LDAP Configuration Example:

LDAP Server	Server Name
LDAP Port	Server TCP Port
Domain	example.plixer.com
Administrator Password	****************
Administrator DN	CN=Example,OU=SampleUser,DC=PLIXER,DC=com
LDAP Server CA Certificate File
Certificate Verification	None
ID Attribute	sAMAccountName
Searchbase	OU=Example,DC=PLIXER,DC=com
Security Groups Allowed	CN=ExampleGroupName,OU=Secutirygroups,OU=Applications,DC=PLIXER,DC=com
SSL Protocol	tlsv1_2
Timeout

Group syncing

When LDAP is enabled and a local usergroup shares the exact same name with an LDAP security group, Plixer Scrutinizer will automatically keep both groups synced by adding or removing users from the local usergroup as they log in.

Examples:

• If a member of the security Group Analysts logs in to Plixer Scrutinizer using their LDAP credentials, they will automatically be added to the local Analysts usergroup (if they were not a member when they logged in).

• If the user is not a member of the Analysts LDAP security group, they will be removed from the local Analysts usergroup (if they were a member when they logged in).

Important

This feature requires the names of the local usergroup and the LDAP security group to be an exact match, including any capitalization and/or punctuation.

LDAP servers

To setup redundancy for LDAP, do the following:

1. Navigate to the Admin > Security > LDAP Servers page.

2. Click Add Server.

3. Provide the following details:

• LDAP server

• LDAP port

• Domain

• Administrator Password

• Administrator DN

• LDAP Server’s CA Certificate File

• Certificate Verification

• ID Attribute

• Searchbase

• Security Groups Allowed

• SSL Protocol

• Timeout

4. Click Save.

Note

When an LDAP user logs in to a Scrutinizer configured with multiple LDAP servers, authentication attempts will be made against each server in the order they appear in that server table until one is successful, else they all fail.

RADIUS configuration

To configure the RADIUS authentication, navigate to the Admin > Security > RADIUS Configuration page and provide the following details:

• RADIUS Server: the hostname or IP address of the RADIUS server;

• RADIUS Timeout: the connection timeout for RADIUS authentication (in seconds);

• Shared Secret: the shared secret for the RADIUS server.

Save the changes and attempt to log in with your RADIUS credentials.

TACACS+ configuration

The TACACS + authentication can be set up via the Admin > Security > TACACS+ Configuration page.

• Pre-shared Key: the pre-shared key for the TACACS+ server.

• TACACS+ Port: the TCP port to use when connecting to the TACACS+ server. The default TACACS+ port is TCP 49.

• TACACS+ Server: the hostname or IP address of the TACACS+ server.

• TACACS+ Timeout: the connection timeout for TACACS+ authentication (in seconds).

Save the changes and attempt to log in with your TACACS+ credentials.

Single sign-on

Scrutinizer-Azure ADFS SAML integration

To set up the Scrutinizer-Azure ADFS SAML integration, first create the application in Azure.

1. After logging in as an administrator, navigate to Azure Active Directory > Enterprise Applications.

2. Click the New Application button.

3. In the Add an Application dialog, choose Non-gallery Application.

4. Enter “Scrutinizer” or any name you prefer in the form that appears, and click Add.

5. Once the application is added, you will be redirected to its Overview page. In the toolbar on the left, click Single Sign-on.

6. Another dialog with authentication options will appear.**Disabled** is selected by default. Click SAML to continue.

7. A form titled “SAML-based sign-on” will have several sections with an “Edit” button in the upper-right of each.

• Basic SAML Configuration

Identifer (Entity ID)	https://<scrutinizer_server>/
Reply URL	https://<scrutinizer_server>/fcgi/scrut_fcgi.fcgi?rm=usergroups&action=sso_response
Sign on URL	https://<scrutinizer_server>/
Relay State	Leave blank
Logout URL	Leave blank

• User Attributes and Claims

  • Click the claim for http://schemas.microsoft.com/ws/2008/06/identity/claims/groups.

  • In the panel that appears, select “Security Groups” for “Which groups associated with the user should be returned in the claim?”

  • Change “Source attribute” to “sAMAccountName” (unless your organization uses a different AD naming attribute).

• SAML Signing Certificate

  • Copy the App Federation Metadata URL value.

  • Download the Certificate (Base64) file. This document will assume the filename is “azure.cert”

• Set up Scrutinizer

  • Copy the Azure AD Identifier value.

Note

The values and the certificate you copied will be required to complete the Scrutinizer configuration.

This completes the Azure configuration. You should now assign users or groups to the Scrutinizer application in Azure ADFS so that they can successfully authenticate.

Scrutinizer configuration

Now that you have the required information from Azure’s configuration, you can set up Scrutinizer’s authentication. Log into Scrutinizer as an administrator and follow the steps below.

1. Using your favorite client or command line, copy the azure.cert to the following directory on your Scrutinizer primary reporter: /home/plixer/scrutinizer/.

2. Navigate to the Admin > Security > Single Sign-On page and click Add Server.

3. In the modal that appears, enter the following values:

Name	Enter any unique identifier you prefer (e.g. “Azure ADFS”)
IdP Identifier URL	Enter the “Azure AD Identifier” URL you previously copied
Entity ID	Enter in the format of https://<scrutinizer_server>/
Assertion URL	Enter in the format of https://<scrutinizer_server>/fcgi/scrut_fcgi.fcgi?rm=usergroups&action=sso_response
Audience Value	Enter in the format of https://<scrutinizer_server>/
Name Attribute	Enter http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name
Groups Attribute	Optional. Enter http://schemas.microsoft.com/ws/2008/06/identity/claims/groups.It will send usergroup names if the company’s IdP is set up to provide them.
IdP Metadata URL	Enter the “App Federation Metadata URL” link you previously copied
IdP Metadata XML	Optonal. Either the Metadata URL or Metadata XML needs to be entered. Rather than initiating a connection with the IdP to fetch the Metadata URL each time, provide the Metadata XML by pasting it in this field
IdP Certificate	Enter “/home/plixer/scrutinizer/azure.cert”

4. Click Save to save the configuration.

A new row will appear in Scrutinizer’s Single Sign-On Admin view. Log out of your user account. You will notice the URL ends in /login – this is the direct access URL to Scrutinizer’s local and third-party authentication form.

Note

With SSO configured, accessing the root of your server (e.g. https://scrutinizer.mycompany.com/) will automatically redirect to Azure ADFS for authentication. If the user or their group has been assigned access to the “Scrutinizer” application in Azure ADFS, they will be granted access. If the local Scrutinizer admin account is needed, or if other authentication methods are configured (e.g. LDAP or RADIUS), the login form can be accessed directly at https://<scrutinizer_server>/login.

Scrutinizer-Okta SAML integration

To enable single sign-on through Okta in Scrutinizer, you must first create the application in Okta.Launch the Okta Classic UI to perform the steps below. If you see “Developer Console” in a dropdown at the top of your page, click it to switch to Classic UI.

1. Select Applications in the navigation bar.

2. Click the Add Application button.

3. In the sidebar, pick the green Create New App button.

4. In the modal that appears, set Platform to Web, tick the SAML 2.0 radio button,and then click Create.

Once a new application is created, you will see page 1 of its General Settings:

5. Enter Scrutinizer for the App name. Click Next.

6. Use the following format for Single sign on URL: https://<scrutinizer_server>/fcgi/scrut_fcgi.fcgi?rm=usergroups&action=sso_response

7. Set Audience URI to: https://<scrutinizer_server>/

8. Skip the other options and click Next, and then Finish.

You will be redirected to the Sign On settings page for the Scrutinizer application.

9. Locate the section of the page that says: “Identity Provider metadata is available if this application supports dynamic configuration.” Enter the link in the following format: https://<okta_server>/app/identifier/sso/saml/metadata

10. Click View Setup Instructions.

11. Set the Identity Provider Single Sign-On URL to: https://<okta_server>/app/application_id_and_name/identifier/sso/saml

12. Use this link for the Identity Provider Issuer: http://www.okta.com/identifier

13. Click the Download Certificate button and save your okta.cert file. We will need to copy it to the Scrutinizer server later.

With the Okta configuration complete, you should now assign users or groups to the Scrutinizer application so that they will be able to successfully authenticate.

Scrutinizer configuration

Now that you have the required information from Okta’s configuration, you can set up SSO authentication in Scrutinizer. Log into Scrutinizer as an administrator and follow the steps below.

1. Using your favorite client or command line, copy the okta.cert you previously saved to the following directory on your Scrutinizer primary reporter: /home/plixer/scrutinizer/

2. Navigate to the Admin > Security > Single Sign-On page and click Add Server.

3. In the modal that appears, enter the following values:

Name	Enter any unique identifier you prefer (e.g. “Okta”)
IdP Identifier URL	Enter the “Identity Provider Issuer” URL you previously copied
Entity ID	Enter in the format of https://<scrutinizer_server>/
Assertion URL	Enter in the format of https://<scrutinizer_server>/fcgi/scrut_fcgi.fcgi?rm=usergroups&action=sso_response
Audience Value	Enter in the format of https://<scrutinizer_server>/
Name Attribute	Enter “nameid” to use the name attribute configured and passed back by Okta
IdP Metadata URL	Enter the “Identity Provider metadata” link you previously copied
IdP Metadata XML	Leave this blank
IdP Certificate	Enter “/home/plixer/scrutinizer/okta.cert”

4. Click Save.

There will be a new row in the Single Sign-On view. Log out of your user account. You will notice the URL ends in “/login”. This is the direct access URL to Scrutinizer’s local and third-party authentication form.

Note

With SSO configured, accessing the root of your server (e.g. https://scrutinizer.mycompany.com/) will automatically redirect to Okta for authentication. If the user or their group has been assigned access to the Scrutinizer application in Okta, they will be granted access. If the local Scrutinizer admin account is needed, or if other authentication methods are configured (e.g. LDAP or RADIUS), the login form can be accessed directly at “https://<scrutinizer_server>/login”

• User Groups: Specifies what a Group login account can access. More details regarding the permissions can be read about under Usergroup Permissions.

• Users: Configure login preferences for individual accounts. User Accounts must be a member of one or more User Groups. If no group is selected when a User Account is created, they are placed in the default (e.g. Guest) User Group. Permissions for a User Account are inherited from all the User Groups it is a member of.

• User Account Lockout: If a user has a specified amount of failed logins within a defined period of time, that user’s account will be set to ‘locked’ status and will require a user with administrative permissions to unlock it.

  These settings are defined in Admin > Settings > System Preferences and include:

• Failed Login Max: the maximum failed logins allowed within the Failed Login Window time

• Failed Login Window: the number of minutes that the Failed Login Max value is matching against
  
  

  For example, with these settings:
  

  Failed Login Max = 2
  Failed Login Window = 5

  Two failed logins within a 5 minute timespan would cause that user account to be locked out.

  To unlock the account, an administrative user needs to go to Admin > Security > Users, select the username that is locked out, then click on the Authentication Method tab in the Edit User modal, and change the Authentication Method from ‘locked’ to the appropriate method.