GFIPM Reference Federation

From GFIPM Implementation Wiki
Revision as of 02:47, 14 January 2011 by Matt.Moyer (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

This article provides background information about the GFIPM Reference Federation. It also provides guidance on how to use the GFIPM Reference Federation to test IDPs and SPs without the concern of exposing sensitive live data.

Introduction and Usage Requirements

The GFIPM Reference Federation contains a collection of Internet-accessible IDPs and SPs that are configured for testing purposes. It also contains an IDP Discovery Service (DS).

GTRI maintains the GFIPM Reference Federation and makes it available to prospective NIEF and other GFIPM program stakeholders members for proof-of-concept and interoperability testing. The federation consists of several core software components located in a laboratory at GTRI, as well as other IDP and SP systems that may be connected to the federation from time to time. The core components of the federation are accessible via the Internet and are generally available 24/7; however, GTRI and other GFIPM stakeholders also use it as a test bed, so some of its components may be unavailable at times. To ensure availability of the GFIPM Reference Federation, GTRI recommends that you arrange an appointment at which to perform your formal testing.

To use the GFIPM Reference Federation, you must meet the following configuration and networking requirements:

  1. Set up and configure your organization's test IDP and/or SP in your test environment.
  2. Your test user(s) should use a workstation (typically a Windows PC) with an industry-standard Web browser (typically Internet Explorer).
  3. Your testing environment must have the following network connectivity:
    1. Your test users must have network connectivity to your IDP.
    2. Your test users should have network connectivity to the Reference IDP. While this is not required, it is a great convenience, because the Reference IDP contains a number of useful test identities that can be used by any test users.
    3. Your test users must have network connectivity to your SP.
    4. Your test users must have network connectivity to the GFIPM Reference Federation SPs and Directory Service (DS) over the Internet.
    5. The GFIPM Reference Federation SPs and DS are listening on ports 80 and 443 on the Internet, so your site must allow outbound traffic on these ports.
    6. Other test users (such as at GTRI) must have network connectivity to your SP over the Internet. This means that your test environment must allow inbound traffic to your SP server, usually on ports 80 and 443 (or possibly other ports depending on your SP).
    7. Note: Inbound traffic from the Internet to your IDP is not required for other test users or SPs unless your own test users need to come in from the Internet (and they are not using a VPN or other security layer). Due to security considerations, participants' IDPs are normally not exposed to the Internet.

Never disseminate live (real) data via the GFIPM Reference Federation. It is imperative that your test IDPs and SPs contain no real data when testing in the GFIPM Reference Federation or any other nonproduction GFIPM testing environment.

Agencies that are interested in the GFIPM program are invited to join the GFIPM Reference Federation to learn more about operating within the federation. By joining the GFIPM Reference Federation, an agency can do all of the following:

  • Verify proper generation and processing of GFIPM Metadata.
  • Verify interoperability with other federation members.
  • Learn how to deploy SAML2 software.
  • Test new deployment strategies.
  • Use test identities to test its SP.
  • Test new services with reference IDPs.
  • Test IDPs with reference SPs.
  • Examine and analyze other agencies' reference SPs.

The early federation components were reference implementations of each major functional component. These reference components were deployed by GTRI, and they serve two purposes. First, the process of deploying and maintaining the reference components serves as a valuable learning experience and a source of documentation artifacts that may be used by other participants. Second, the reference components themselves provide a valuable testing platform for each organization's IDP and/or SP deployments. Each reference component is discussed individually in the subsections below.

Reference Identity Provider (IDP)

GTRI deployed two reference IDPs in the pilot federation. Both IDPs are based on the Shibboleth 2.x implementation of SAML 2.0. One of the reference IDPs is deployed on a Microsoft Windows platform, the other on Red Hat Enterprise Linux (RHEL). There is no functional difference between a Shibboleth IDP running on Windows and one running on RHEL; however, the deployment processes for a Shibboleth IDP on each platform are different enough to merit the task of working through each and documenting them separately. During and after the deployment process, GTRI created a detailed set of instructions for deploying a Shibboleth IDP on each platform.

Both IDPs address two integration issues. The first is the Single Sign-On Integration Point, which involves the integration of the IDP with the local site's user authentication system, and the other is the Attribute Authority Integration Point, which involves connecting the IDP to the local site's attribute repository.

During the deployment of the reference IDPs, the Windows-based reference IDP was integrated with a username/password authentication system, and the RHEL-based reference IDP was integrated with a PKI-based client certificate authentication system. At the Attribute Authority Integration Point, both reference IDPs were connected to a reference LDAP repository.

Since their deployment, it has become clear that both reference IDPs are very useful during the process of deploying new SPs. They contain a large number of test identities that are designed to allow for testing a wide variety of metadata attributes. Additional credentials for test accounts on each reference IDP can be provided to new participants, and these test accounts have repeatedly proven to be a valuable resource for participants who have brought their SPs online.

Some of the current participants continue to maintain their reference IDPs online on a full- or part-time basis. For example, CISA maintains its reference IDP (a full test copy of its production IDP) for its testing use. On request, CISA administrators and users can test other participants' reference SPs with their reference IDPs.

Other reference IDPs are occasionally available in the GFIPM Reference Federation. These IDPs belong to other participants and can be used only by the users of those participants.

A representative list of reference IDPs can be seen in the drop-down menu in Figure 4.

Ds-screen-shot.png

Figure 4: Screen Shot Containing a List of Available Reference IDPs

Reference Service Provider (SP)

In addition to deploying reference IDPs, GTRI has also deployed two reference SPs in the GFIPM Reference Federation. Both SPs are based on the Shibboleth 2.x implementation of SAML 2.0. As with the reference IDPs, one of the reference SPs was deployed on a Microsoft Windows platform, and the other on RHEL. Again, as with the reference IDPs, there is no functional difference between a Shibboleth SP running on Windows and one running on RHEL; however, the deployment processes for a Shibboleth SP on each platform are different enough to merit the task of working through each and documenting them separately. During and after the deployment process, GTRI created a detailed set of instructions for deploying a Shibboleth SP on each platform.

The integration work required for an SP involves setting up the SP to provide protected access to sensitive resources. During the deployment of the reference SPs, GTRI created some simple HTML and PHP pages to serve as protected resources. These pages serve two important purposes. First, they help participants debug various problems with their IDPs at the SAML configuration level. Second, they allow for careful inspection of the GFIPM user metadata that an IDP sends to a reference SP. This feature has been very valuable in helping participants identify and correct problems related to the generation of metadata by their IDPs.

As with the reference IDPs, participants have found the reference SPs to be useful during the deployment process for their infrastructure. Participants are able to test their IDPs by attempting to access resources on the reference SPs.

Some of the current participants continue to maintain Reference SPs online within the GFIPM Reference Federation on a full- or part-time basis. For example, CISA maintains a reference SP for its testing use. The CISA reference SP provides links to test resources for testing purposes and can also be used to test the user metadata from another participant's IDP. Other reference SPs from other participants may occasionally be available in the GFIPM Reference Federation. When available, these SPs can be used by the users of any participant with a referenced IDP or by using the GFIPM Reference IDP.

Reference IDP Discovery Service (DS)

The final reference component in the GFIPM Reference Federation is the IDP Discovery Service (DS). The DS allows a convenient means for a user to specify which IDP he or she would like to use for single sign-on within the federation. The GFIPM Reference Federation currently uses a single DS, which is managed by GTRI; however, there is no inherent limitation on the number of discovery services that a federation can use.

Figure 4 depicts a Web page generated by the Reference Discovery Service.

Participants in a GFIPM federation need not implement their own Discovery Service. Instead, your Service Providers can redirect to the central DS when a user tries to access a resource without a SAML assertion. If a participant's Service Provider solution cannot interface with the DS, the SP must provide an equivalent functionality.

Useful GFIPM Reference Federation Information

The GFIPM Reference Federation contains useful test documentation as well as reference SPs and IDPs, the Discovery Service, and the signed federation trust fabric document. These items are summarized below with their respective URLs.

  • GFIPM Reference Federation Home: http://ref.gfipm.net/
    This Web site offers an introduction to current members and prospective members of a GFIPM federation for the purpose of getting started using the GFIPM Reference Federation. The GFIPM Reference Federation is a public federation that agencies interested in GFIPM are invited to join to learn more about operating within a federation. Topics covered on this Web site include the following:
    • Overview and purpose
    • Information for participating
    • Members and their reference resources
    • Downloads page
    • FAQ
    • How to get more help
  • Reference SP: https://rhelsp.ref.gfipm.netThis test Service Provider contains one Shibboleth Protected Resource, which acts as a protected resource that requires authentication at a GFIPM Reference Federation IDP. When you try to use the resource, you will be redirected to the GFIPM Reference Federation's Directory Service.
  • Reference IDP: https://rhelidp.ref.gfipm.netThis test Identity Provider contains multiple test GFIPM user attribute sets for use by federation members in SAML assertions for testing. These attribute sets are suitable for testing a new Service Provider in the GFIPM Reference Federation. The attribute sets represent identities with a wide variety of authentication and privilege information. There are also multiple similar user attribute sets that vary only slightly among themselves so that testers can observe small privilege changes on their SPs.Important: Because these user attribute sets do not represent real people, they must not be used to access live data.
  • GFIPM Reference Federation IDP Discovery Service (DS): http://ref.gfipm.net/ds/The DS is a service that performs the task of discovering the user's IDP and providing that information to the SP so that the SP knows which IDP to use in the subsequent SSO process.
  • Federation Trust Fabric File: http://ref.gfipm.net/gfipm-signed-ref-metadata.xmlA document signed by the Federation Manager Organization, containing trusted information about each IDP and SP in the federation. It includes X.509 certificate data for each software entity, as well as a GFIPM Entity Assertion providing various informational attributes about each entity. This GFIPM Trust Fabric is the cryptographic trust anchor for all federation transactions. Before any new SP or IDP can join the GFIPM Reference Federation, the federation manager must first enter it into this file. All operational SPs and IDPs must download and use this file. In addition, the providers must periodically check for new versions and download them (new versions are typically announced to the participant administrators by e-mail).
  • CISA Reference SP: https://cisasp.swbs.gtri.gatech.eduThis is a complete test version of the CISAnet production SP with test resources and access control rules suitable for testing IDPs and test user identities.