Single sign-on (SSO) and Mascot

Mascot Server has a role-based security system called Mascot Security. Common use cases are restricting access to configuration files or specific sequence databases, or imposing limits on search size or duration for specific users or groups. These were discussed in earlier blog articles Mascot Security: priority settings and Mascot Security: privacy settings.

Mascot Security isn’t designed to have super secure authentication or prevent a determined hacker from gaining unauthorised access. If the installation security is a concern, we always recommend keeping your Mascot server behind a firewall or otherwise restricting access to it using a strong authentication system. We sometimes get asked whether Mascot can be integrated with systems like Microsoft Active Directory (AD) or various single sign-on (SSO) systems. The short answer is yes. The long answer is, all the heavy lifting is done by the web server. Mascot itself has no direct integration with authentication systems.

The diagram below illustrates the integration. The web browser, or a third-party client program, makes an HTTP/HTTPS request to the web server. If the web server (IIS or Apache) is configured to authenticate users, it will interact with an authentication system, like AD. If authentication succeeds, the web server uses the Common Gateway Interface (CGI) to run the requested Mascot program or script. The name of the authenticated user is passed in the REMOTE_USER environment variable. The script matches this to the Mascot Security user database (user.xml, group.xml). If the user exists, they are “logged in” to Mascot without prompting for a password.

The key steps in configuring Mascot Security are: the Mascot user name must match the external user name; the Mascot user must be configured to use web server authentication; and guest access must be disabled. I’ll illustrate this by configuring basic access authentication in IIS on Windows.

Let’s say your full user name is COMPANY\jqpublic, where COMPANY is the domain name. The first step is enabling the Basic Authentication feature in Windows. Then, in IIS Manager, go to the local server settings (http://localhost) and Authentication. Enable the Basic Authentication module. In the ‘mascot’ website settings, under Authentication, enable the Basic Authentication module and disable Anonymous Authentication. Set the authentication domain to COMPANY. The steps, including screenshots, are documented in detail in Microsoft Docs.

Now open http://localhost/mascot in a web browser. The browser should prompt you for login credentials. In Basic authentication, these are your domain login (jqpublic) and your usual password. If you close the browser and open the Mascot front page again, the browser will ask for login credentials again.

On the Mascot side, enable Mascot Security as described in chapter 12 of the Installation & Setup manual. Log in as admin from the Mascot front page. There are now two active authentication layers: you’re logged in to the web server as jqpublic, and you’re logged in to Mascot Security as admin. You can confirm the latter by viewing current session information from the Mascot home page.

Go to Configuration Editor, Security. Make sure the ‘guest’ user is disabled. Create a user jqpublic and set user type to “User authenticated using web server”. Leave the password field empty. The user name must not contain the domain name or any backslashes.

Save, and on the Mascot front page, log out from admin. Go back to the Mascot front page. If you now view current session information in Mascot, it should give the session ID as jqpublic_webserverauth, which means you are logged in as jqpublic in Mascot Security. The user name is transmitted by the web server in the REMOTE_USER environment variable, and Mascot successfully mapped it to a user configured in Mascot Security.

Basic access authentication is, as the name says, very basic and not very secure. However, configuring Mascot to integrate with it is exactly the same as configuring integration with Active Directory, LDAP, Kerberos or any other authentication system. The onus is on the web server to perform authentication and pass the correct user name on to Mascot. Configuring a web server for secure single sign-on authentication is a general IT task and outside the scope of a single blog post!

In a large-scale system, it’s convenient to be able to automate adding users to Mascot’s user database. Mascot ships with an example Perl script add_user.pl. By default, the script creates a normal user, but it’s straightforward to edit the script and change the user type to web authentication.

For more details about Mascot Security, have a look at chapter 12 of the Installation & Setup manual or module L of the online training course.

Keywords: configuration files, security, sysadmin