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”
by Leroy Altman
As you may have heard, Stanford is moving away from their in-house created authentication software known as “WebAuth” to an industry standard Open Source technology called SAML2. Software called “Shibboleth” is available to leverage SAML2 and it includes a version created for Microsoft’s Internet Information Server (IIS) web server running on Windows.
This article was gathered from two great sources listed below, and I encourage you to read both for more details. This article is really just the tip of the iceberg:
There are two new terms to know:
- Identity Provider (IDP): This is Stanford’s central authentication service
- Service Provider (SP): This is your web server
Installation: This is a quick summary of how to get Shibboleth installed and working on a Windows IIS web site.
- Windows Server 2012 R2 w/ IIS installed.
- In addition to the default IIS modules, you’ll also need to add Management Compatibility components:
- IIS 6 WMI
- IIS 6 Metabase compatibility
- IIS 6 Scripting tools
- IIS 6 Management Console
- Install ISAPI filter and Extensions [located in Web Server (IIS) → Web Server → Application Development]
- A “Default Web Site” which has a default page, used for testing.
- A “/secure” subfolder under the root, also with a test page.
- An SSL certificate installed and working on the website.
Run the Shibboleth Installer. The most recent version, as of this writing, is here: https://shibboleth.net/downloads/service-provider/2.6.1/win64/
The defaults for installation are typically fine to use:
Continue reading “Shibboleth Authentication on IIS”
by Jonathan Lent
Like many developers, application maintainers, and system administrators at Stanford, I’ve been focussing a lot of time lately on migrating legacy web applications to using Shibboleth (from WebAuth). Also like many, I’ve found Alex Tayts’ article Migrating away from WebAuth: practical steps very useful during this process. However, as straight-forward as that writeup is, it doesn’t account for one thing: the Shibboleth SP software is not perfect.
During a recent deployment, I found that by simply enabling the shib2 Apache module on systems with Apache 2.4 running, applications using multiple AuthTypes (e.g. WebAuth and basic authentication) were suddenly presenting a 401 (Unauthorized) error message. This was before adding any directives to use Shibboleth as the AuthType.
Continue reading “Shibboleth on Apache 2.4 Using Mixed Authentication Methods”
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”