Security¶

Auditing Report: Displays a report of all the administrative actions users have performed within Plixer Scrutinizer.
Authentication: Configure general authentication settings, enable or disable different technologies, permit or deny specified groups or named users the ability to use one or more of the supported authentication methods, and set the order in which methods are attempted.
Authentication Tokens: These tokens can be used to automate Plixer 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¶

In the LDAP configuration, the administrator provides credentials for an LDAP service account with permission to perform searches of the remote LDAP directory.

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

The searchbase identifies the location in the LDAP tree from where the search begins, typically in an OU below the domain level to reduce the scope of the search and improve search performance. This is a required field.

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

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.

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

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

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

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

LDAP Configuration Example:

LDAP Server	`Server Name`
LDAP Port	`Server TCP Port`
Domain	`example.plixer.com`
Administrator Password	`****************`
Administrator DN	`CN=ExampleUserName,OU=OptionalOU,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=Securitygroups,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 provide LDAP server redundancy, simply configure multiple distinct LDAP servers on the Admin > Security > LDAP Servers page.

Note

When an LDAP user logs into a Plixer Scrutinizer server configured with multiple LDAP servers, authentication attempts will be made against each server in the order they appear in the LDAP Server list until one is successful, otherwise the user authentication fails.

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¶

Plixer Scrutinizer-Azure ADFS SAML integration¶

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

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

Click the New Application button.

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

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

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

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

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 Plixer Scrutinizer
- Copy the Azure AD Identifier value.

Note

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

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

Plixer Scrutinizer configuration

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

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

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

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”

Click Save to save the configuration.

A new row will appear in Plixer 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 Plixer 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 “Plixer Scrutinizer” application in Azure ADFS, they will be granted access. If the local Plixer 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.

Plixer Scrutinizer-Okta SAML integration¶

To enable single sign-on through Okta in Plixer 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.

Select Applications in the navigation bar.

Click the Add Application button.

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

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:

Enter Scrutinizer for the App name. Click Next.

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

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

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

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

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

Click View Setup Instructions.

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

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

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

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

Plixer Scrutinizer configuration

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

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

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

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”

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 Plixer 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 Plixer Scrutinizer application in Okta, they will be granted access. If the local Plixer 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, the following settings will lock a user account out after two failed logins within a 5-minute timespan:
  
  Failed Login Max = 2
  Failed Login Window = 5
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.