This article describes a very generalized outline of how to integrate a third party application with Stanford Identity using SAML. Since all applications are different, there cannot be a single recipe covering all possibilities. Some of the integration decisions depend on the authentication architecture of an application, specifics of the Stanford environment and the user base of the application.
This article is written for a wide audience and begins with the very basics, avoids most of the special terminology, but gradually gets more technical. If at any point you feel like you need assistance with setting up an integration, feel free to stop reading and submit a HelpSU ticket.
Single Sign-On (SSO) is an authentication scheme, which allows a user to login to multiple independent applications using the same set of credentials. At Stanford everyone is familiar with a Web Login page, where one enters his SUNet ID, password and requests a Duo prompt. The same login page shows up no matter which application one is logging into. If you need the same kind of login capability for a third party application or service, keep reading.
Continue reading “Integrating a Third Party Application with Stanford SSO”
This year, I have been working with one of our clients on a typical research-oriented server setup, including a few compute servers mounting a single shared storage over NFS, which is a common and well-tested configuration. The main difference for this project was the size of the storage. At the time when our team became engaged with this client, they were using ten assorted storage servers based on Linux and FreeNAS. In order to replicate the data between these servers, rsync was being used. Additionally, an elaborate scheme was in place to make sure that each dataset is housed on at least two different servers. All of the storage servers were outdated and out of warranty, so the client agreed to procure new hardware and build a new setup from scratch.
Following the example of Research Computing team, Ubuntu was selected as a base operating system for both compute and storage servers deployed on commodity Supermicro hardware resold by Colfax. Cost-effectiveness of the deployment was deemed as a decisive factor by the client. To achieve the maximum storage density, a client opted for a single 60-drive primary storage server with ZFS file system. ZFS brings with it all the advantages of a copy-on-write file system with features, such as instant copy, snapshots, flexible volume management, built-in NFS sharing, error resilience and correction.
Below I am going to discuss SEND/RECEIVE feature of ZFS, which allows to easily and efficiently replicate large volumes of data.
Continue reading “Efficient Data Replication with ZFS”
Unlike Apache, nginx does not have a module like mod_shib interacting directly with Shibboleth daemon shibd. I will use a module ngx_http_shibboleth_module, which uses FastCGI protocol to talk to Shibboleth daemon through sockets. Shibboleth comes with two FastCGI modules:
- FastCGI responder (shibresponder) that handles the HandlerURL
- FastCGI authorizer (shibauthorizer) that acts as a filter and does the usual (authN, export assertions and authZ).
Of course, these modules have to be running alongside the shibd daemon. Let’s start with Shibboleth setup and configuration. I used Ubuntu 16.04 LTS (Xenial) for the setup described in the article, but it can be easily ported to other versions of Linux.
There are some guides around on how to get such configuration working, but all of them seem to be missing one or more crucial steps. This is the drawback which I tried to remedy with this article.
Continue reading “Using Shibboleth with nginx”
Stanford University is in the process of migrating from its homegrown authentication system, WebAuth, to the widely deployed and feature-rich SAML-based authentication. This brings a lot of benefits, like better compatibility, wider application support and easy federation with other institutions.
There are multiple SAML (Security Assertion Markup Language) implementations, but this article is focuses on two of them, Shibboleth and SimpleSAMLphp.
Shibboleth is well-documented and there are Stanford UIT documentation pages with high level descriptions of how it fits into the Stanford infrastructure. In this article I will talk about the practical steps one has to take to migrate from WebAuth to Shibboleth or SimpleSAMLphp, how to set them up and what adjustments have to be made to the configuration files on the SP (Service Provider) side.
Parts of the article are a rehash of the official UIT Shibboleth documentation with some corrections and explanations of the steps pertinent to the topic of migration from WebAuth. The content is based on our client’s questions and the issues we encountered while performing these migrations for our clients. Continue reading “Migrating away from WebAuth, practical steps”