This is the first part of a two-part blog series that shows how to set up a “sandbox” environment of Global Federated Identity and Privilege Management (GFIPM) components using open source software and Docker containers:

  • Part I provides some background on GFIPM, Security Assertion Markup Language (SAML), and open source software available to implement GFIPM/SAML
  • Part II shows how to use Docker to deploy these open source components in a sandbox environment

The approach presented in this blog series demonstrates that it is straightforward to implement GFIPM using freely-available, open source software.  Using Docker allows us to “package” these implementations for easy reuse and deployment–both in a “sandbox” environment for testing and demonstration purposes, as well as in a production setting, using simple Docker images as a base for building more robust and secure images for real-world scenarios.  The key takeaway, though, is this:  Implementing GFIPM need not be expensive or difficult, and the approach presented here shows how.

Introduction

The Global Federated Identity and Privilege Management (GFIPM) guidance represents the national justice community’s best thinking on how to implement federated identity.  It provides a reference architecture that explains the principal components involved in a federated identity approach, a metadata standard that enables interoperable sharing of credentials across jurisdictions, and profiles for technical interoperability in system-to-system and user-to-system scenarios.  It has been successfully implemented in several jurisdictions, and is well-aligned with national whole-of-government initiatives, like the Federal Identity, Credential, and Access Management (FICAM) program and the National Strategy for Trusted Identities in Cyberspace (NSTIC).  The OJBC has, for several years, supported its Member jurisdictions in implementing GFIPM federations, and the OJB platform includes robust support for GFIPM and the Security Assertion Markup Language (SAML) standard on which it is based.

Since its early days, GFIPM has included a reference federation to assist implementers in interoperability testing.  This has proven very useful in helping jurisdictions set up SAML components.  However, there are circumstances in which a local federation can be very helpful in experimentation, development, and testing.  For example, a developer or architect may wish to set up an identity provider or service provider (more on these terms later) and test those components within the context of other components that are known to work, in order to verify the integrity of the component under construction.  Or, a developer may wish to deploy an application within a working federation to test how the integration works, but would rather avoid the expense of time and effort needed to set up all the federation components.  In either scenario, users may wish to have an environment entirely under their control, without dependencies on outside organizations or resources.

In this blog post, we will demonstrate setting up a simple GFIPM “sandbox” federation on a single machine using Docker containers.  Docker is an application development platform that enables developers and system administrators to define applications in terms of packaged components that run in relative isolation from one another–in many cases, as if those components were running on separate servers, even though they are actually running in a single instance of an operating system.  Docker runs natively on Linux, but through a “wrapper” approach called Docker Machine, it can be run on MacOS and Windows as well.  There is a great deal of information available on Docker, from “getting started” tutorials to in-depth guides, that we will not attempt to replicate here.  You may want to familiarize yourself with Docker a bit at https://docs.docker.com.

With your local installation of the sandbox, you will be able to work through the scenarios mentioned above, or use the OJBC Dockerfiles as the basis for developing your own GFIPM Docker images.

The Basic Components of a Federated Identity Approach

In a federated identity scheme, organizations that own or operate data sources, services, or applications are called relying parties, because they “rely” on other entities to authenticate users, determine attributes of those users, and make claims about those users, in the form of assertions.  Those “other entities” that perform the authentication and make these assertions are called identity providers.  Identity providers typically use some kind of directory service, such as a Lightweight Directory Access Protocol (LDAP) server or a Microsoft Active Directory server, to perform actual authentications and retrieve user attributes.  These components work together as depicted in this diagram:

GFIPM1

 

The steps are:

  1. User requests a secure web page in their browser
  2. Browser sends request to the web application (relying party), which is protected by the Service Provider
  3. The Service Provider notices that it does not have a session for this user, so forwards the request to the Identity Provider
  4. After prompting the user to authenticate, and using the “User Store” (directory) to confirm the authentication and collect any user attributes, forwards an assertion back to the Service Provider
  5. After servicing the user’s request, the Service Provider (utilizing the web/portal server–typically, a web server, which may utilize an application server in the backend) returns the response back to the browser
  6. Browser displays page/resource to the user

For more detail on how the basic SAML web single-signon protocol works, consult the GFIPM Implementation Guide.  There are more complex versions of this basic scenario discussed in the Implementation Guide and the other GFIPM Documentation, but we will not explore those scenarios here.

Setting up GFIPM with Open Source Software

There are several open source software options for implementing each of the components in a GFIPM federation.  The ones we will use are:

In Part II, we will install these components (including Apache DS as our directory server), as well as the Apache Tomcat web application server, inside Docker containers to set up a working local federation.