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
  1. 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.
  2. 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.
  3. If the LDAP server responds with an LDAP_REFERRAL code, Scrutinizer will check the referred server.
  4. If the Scrutinizer administrator has specified multiple LDAP servers, it will check them all until successfully authentication succeeds or fails.
  5. 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.

Note

With LDAP enabled, if you create a usergroup in Scrutinizer that has the same name as a security Group on the LDAP server, when a Scrutinizer user logs in they will automatically be added or removed from the Scrutinizer usergroup to keep Scrutinizer synchronized with the LDAP security groups.

For example, if you have a “Scrutinizer Users” User Group in Scrutinizer and a “Scrutinizer Users” security group in LDAP, when that user logs into Scrutinizer with their LDAP credentials and is a member of the LDAP Security Group “Scrutinizer Users”, that user will automatically be added to the Scrutinizer “Scrutinizer Users” User Group.

If the LDAP user is not a member of the “Scrutinizer Users” security group in LDAP, when that user logs into Scrutinizer, they will be removed from the Scrutinizer “Scrutinizer Users” User Group.

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 Login URL value.
    • Copy the Azure AD Identifier value.

Note

The valies 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.
Login URL Enter the “Login URL” you previously copied
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”
  1. 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:

  1. Enter Scrutinizer for the App name. Click Next.
  2. Use the following format for Single sign on URL: https://<scrutinizer_server>/fcgi/scrut_fcgi.fcgi?rm=usergroups&action=sso_response
  3. Set Audience URI to: https://<scrutinizer_server>/
  4. Skip the other options and click Next, and then Finish.

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

  1. 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
  2. Click View Setup Instructions.
  3. Set the Identity Provider Single Sign-On URL to: https://<okta_server>/app/application_id_and_name/identifier/sso/saml
  4. Use this link for the Identity Provider Issuer: http://www.okta.com/identifier
  5. 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
Login URL Enter the “Identity Provider Single Sign-On URL” you previously copied
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”
  1. 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.