How to Implement a GFIPM Service Provider

This article outlines the steps necessary to implement a GFIPM Service Provider (SP).

Developing a GFIPM Information Sharing Plan for an SP

During this process, you will accomplish the following:

1. Develop a list of your local resources to which you want to allow access for other organizations' users.
2. Determine your organization's business rules for granting access to your local resources.
3. Using your business rules, develop and codify the access control policies for your resources in terms of the GFIPM user metadata.
4. Fill out a Local Access Policy Mapping Form for your SP.

Identify Local Resources

This section will help you identify local resources that may be useful to other federation members and to determine whether they can be made available to other organizations' users under certain access rules.

Service Providers need to determine which production resources they should make available to other federation members. An equally important consideration is which of these resources can be permitted to be made available and how long the decision making process will take. Federation members typically "own" some resources; in other words, the federation member administers the resource or otherwise has control over access decisions. For these resources, the decision to make the resource available to federation users may be easy. But some federation members may be distributing data that belongs to another organization. In this case, receiving permission to release the data may be more complex and time consuming. The required timelines for gaining permission to make resources available within a federation need to be built into an SP's implementation schedule.

Resources that might be useful to other law enforcement organizations include the following:

• Arrest records
• Incident reports
• Criminal history reports
• Criminal justice reports
• Criminal investigative reports
• Criminal intelligence reports
• Counterterrorism notifications
• Driver's license records
• Public safety messages
• Other federal/state/tribal/local law enforcement information

Types of resources that would be less useful but still of potential interest to federation users include the following:

• Amber Alerts (i.e., missing child alerts)
• Sex offender information
• Other publicly available information

As part of the process of determining which local resources are to be made available, you must also collect the appropriate authority-to-operate documents for providing those resources to federation users.

Determine Business Rules for Resources

For each resource you identified, you must now collect or document its access policy.

It is likely that all of the identified resources already have documented access policies. For example, a resource's access policy might be as simple as the following:

• Any user who is a sworn law enforcement officer may access this resource.

Or a resource's access policy might be more complicated, such as this:

• The user must be a sworn law enforcement officer.
• The user must also have NCIC certification and criminal history privileges.

Many resources with their access policies are listed on the NIEF federation Web site at https://nief.gfipm.net/ for NIEF participants.

In the unlikely event that your organization does not already have documented access control policies, you will need to work through the process of writing them and getting the appropriate approval(s) to provide those resources to federation members.

Develop Access Control Rules

This section uses the business rules from the previous section to guide you through the process of codifying the rules in terms of the GFIPM user metadata.

Note that this section uses the NIEF federation as an example for developing access control rules. Specifically, this section relies on the required and recommended attributes in a SAML assertion. If you are building an SP for a different federation, your set of metadata attributes may be different. However, it is likely that there will be many similarities to the NIEF requirements.

The access control rules are written in terms of attributes in the GFIPM user metadata. The minimal access requirements that a user identity must contain are the following fields:

• User's Last Name
• User's First Name
• User's Phone Number
• User's E-mail Address
• User's Federation ID
• User's Home Organization Name
• User's Identity Provider Name

The above fields are typically used for auditing purposes by a Service Provider to meet the "Federation Login" requirement. Because these attributes do not assert any permissions or privileges, a user identity that contains only the above attributes typically will not be granted access to any law enforcement resources.

Fill Out Local Access Policy Mapping Form

This section will help you fill out a Local Access Policy Mapping Form to translate your plain-English access policies into Boolean logic rules based on GFIPM metadata attributes. The Local Access Policy Mapping Form for your SP is later used as part of your request for federation membership.

The Local Access Policy Mapping Form is a document describing how the organization plans to map its local access control policies into rules that can be expressed using attributes from the GFIPM Metadata standard.

When the federation manager reviews your application package, it will provide a copy of your Local Access Policy Mapping Form (for an SP) to all existing members for review and comment.

The Local Access Policy Mapping Form should be written as a spreadsheet (i.e., Microsoft Excel). A template of this form is included with the membership application forms provided by the federation manager when you request to join the federation.

Before editing the file, you should rename it to include your SP name in the file name.

Below is an example of the design of the spreadsheet, including the headers followed by several rows describing access policy mappings. Note that these examples are from different members, so their derivations are not related to each other.

GFIPM Access Control Policy Map - Service Provider Name: <Your Organization>
	Policy for Resource Discovery		Policy for Resource Access
Service/Resource Name	Semantic Intent	GFIPM Boolean Logic	Semantic Intent	GFIPM Boolean Logic
Arizona Counter-Terrorism Information Center	Any user with a valid federation login may discover this resource.	ALLOW if: (Given Name is present AND Surname is present AND Telephone Number is present AND Federation ID is present AND Employer Organization Name is present AND Identity Provider Name is present)	Any user with a valid federation login may access this resource. In addition, sufficient audit data is required for all users.	ALLOW if: (Given Name is present AND Surname is present AND Telephone Number is present AND Federation ID is present AND Employer Organization Name is present AND Identity Provider Name is present)
New Mexico Complete Arrest Information	Any user with a valid federation login may discover this resource.	ALLOW if: (Given Name is present AND Surname is present AND Telephone Number is present AND Federation ID is present AND Employer Organization Name is present AND Identity Provider Name is present)	To access this resource, a user must be a sworn law enforcement officer with NCIC criminal history certification and criminal history home data search privileges. In addition, sufficient audit data is required for all users.	ALLOW if: (Given Name is present AND Surname is present AND Telephone Number is present AND Federation ID is present AND Employer Organization Name is present AND Identity Provider Name is present) AND (Sworn Law Enforcement Officer Indicator = TRUE) AND (NCIC Certification Indicator is present AND (Criminal History Home Search Data Privilege Indicator = TRUE)

In the above table, you must have a row for every local resource that your SP will make available and then explain the policy for resource discovery and the policy for resource access and the corresponding access control rule expressed in GFIPM Metadata attributes.

If you would like additional examples of a Local Access Policy Mapping Form, please contact the federation manager at gfipm-support@lists.gatech.edu.

At this point, you should have completed the Local Access Policy Mapping Form.

Submitting a Request for Federation Membership

This section serves as a supplemental aid to the membership application process by listing the membership documents that must be collected or developed during the SP implementation process. The authoritative document for this process in NIEF is the Operational Policies and Procedures document [GFIPM OPP]. This section of this document is not a substitute for the OPP document.

The membership process follows these four phases:

1. Request-to-join process
2. Application process
3. On-boarding process
4. Ongoing membership

While working through the SP implementation process, you should collect or develop the following membership documents required above.

1. Authority-to-Operate (ATO) Document(s): Document(s) attesting to the organization's authority to operate as a service provider and make available electronic resources belonging to, or under the legal control of, a specific legal jurisdiction. An ATO document typically takes the form of a signed memorandum or letter from the organization's executive officer to the federation manager.
2. Local Security Policy Document: A document describing the security policy that is currently in place within your organization. This document should already exist within your organization.
3. Local User Agreement Document: A document describing the terms and conditions to which your users must agree as a prerequisite for using a digital identity issued by your organization. This document should already exist within your organization.
4. Local Privacy Policy Document: A document describing the policies that govern the practices of maintaining the privacy of users visiting the organization's service provider or portal. This document should already exist within your organization.
5. Local Access Policy Mapping Form for Your SP: A document describing how the organization plans to map its local access control policies into rules that can be expressed using attributes from the GFIPM Metadata Specification [GFIPM Metadata].
6. Implementation Documentation Form for Youe SP: A document describing how your local federation-aware infrastructure is implemented.

Other documents are required for the membership application process, but these are outside the scope of this implementation guide.

Choosing an SP Product

This section outlines the requirements for products that may be considered for a GFIPM Service Provider (SP). We also present the list of products of which we have knowledge.

An SP is responsible for managing access to applications, services, and other resources used by federation users. To do this, it relies on Identity Providers (IDP) to assert information about users, leaving the SP to manage access control and dissemination based on the trusted set of attributes it receives for each user. There can be an arbitrary number of SPs in a federation, and each SP can manage an arbitrary number of resources.

An SP handles the management of access to protected resources based on information given to it by an IDP. To perform their respective roles, an IDP and an SP need to communicate with each other, and the standard through which this communication occurs in GFIPM is the Security Assertion Markup Language [SAML2].

SAML was developed by the Organization for the Advancement of Structured Information Standards (OASIS) Security Services Technical Committee (SSTC). It is an XML-based framework for communicating user authentication, entitlement, and attribute information. As its name suggests, SAML allows business entities to make assertions regarding the identity, attributes, and entitlements of a subject (an entity that is often a human user, but may be an application or system) to other entities, such as a partner company or another enterprise application.

A GFIPM SP must meet the following minimum requirements:

1. It must conform to the SAML 2.0 Web Single Sign-On (SSO) Profile [SAML2], including support for both SP-initiated SSO and IDP-initiated SSO.
2. It must be able to discover the user's IDP, by either supporting the OASIS Identity Provider Discovery Service Protocol and Profile or implementing a local IDP Discovery Service at the SP.

See [GFIPM U2S Profile] for a thorough, normative specification of the technical requirements that a GFIPM SP must meet.

Any SP product chosen for a GFPIM federation must be SAML 2.0-compatible. It must implement the Web Single Sign-On (SSO) Profile and support SP-initiated Web SSO. Further, it must support parsing and processing of SAML attributes containing GFIPM user metadata.

The following is a non-exhaustive list of products that provide SAML-based Service Provider capabilities. You should evaluate these and other products to determine which product best meets your needs and your budget.

Shibboleth SP

Shibboleth is a standards-based, open-source software package for Web single sign-on across or within organizational boundaries. It allows sites to make informed authorization decisions for individual access of protected online resources in a privacy-preserving manner. It was developed by the Internet 2 project using the OpenSAML open-source implementation of SAML.

The GFIPM federation extends the authorization functions to include privilege management for the justice community and partner organizations with a standards-based approach for implementing federated identity. Note that Shibboleth has separate components that act as an IDP and an SP.

Several components of the GFIPM Reference Federation are implemented using Shibboleth, including the Reference IDP, the Reference SP, and the production CISA IDP and SP.

Existing federation members and technical support staff have extensive implementation experience with Shibboleth. The GFIPM reference IDP and SP use Shibboleth. The Shibboleth product Web page is available online at https://spaces.internet2.edu/display/SHIB2.

Ping Identify PingFederate SP

PingFederate is a commercial product marketed by Ping Identity (www.pingidentity.com). It supports Internet Single Sign-On, Internet User Account Management and Identity-Enabled Web Services. Note that the PingFederate Internet Identity Security Platform can act as both an IDP and an SP.

CA Federation Manager SP

Federation Manager is a commercial product marketed by CA (formerly Computer Associates, www.ca.com). It provides standards-based identity federation capabilities that enable the users of one organization to easily and securely access the data and applications of another. It delivers support of federation standards, including SAML, enabling both Identity Providers and Service Providers. CA Federation Manager also provides for the administration of federation partnerships. Note that CA Federation Manager can act as both an IDP and an SP. Its product Web page is at http://www.ca.com/us/products/Product.aspx?ID=8231.

Sun OpenSSO SP

The Sun Open Web SSO project (OpenSSO, https://opensso.dev.java.net/) provides core identity services to simplify the implementation of transparent single sign-on (SSO) as a security component in a network infrastructure. OpenSSO provides the foundation for integrating diverse Web applications that might typically operate against a disparate set of identity repositories and is hosted on a variety of platforms such as Web and application servers. This project is based on the code base of Sun Java System Access Manager ( http://www.oracle.com/us/products/middleware/
identity-management/oracle-access-mgmt/index.html ), a core identity infrastructure product offered by Oracle (formerly Sun Microsystems, www.oracle.com). Sun OpenSSO is available as an open-source solution or as a commercialized packaged product from Oracle with support. Note that Sun OpenSSO can act as both an IDP and an SP.

Oracle Identity Federation SP

Identity Federation is a commercial product marketed by Oracle (www.oracle.com). It is part of the Oracle Identity & Access Management Suite. Note that Oracle Identity Federation can act as both an IDP and an SP. Its product Web page is at http://www.oracle.com/products/middleware/identity-management/identity-federation.html .

Implementing a GFIPM SP

This section provides an overview of the logical structure of a GFIPM SP and also guides the reader through the process of implementing a GFIPM SP at a high level.

After choosing an appropriate SP product, the next step is to implement a GFIPM SP. This document cannot provide exhaustive details covering all possible implementation scenarios because of the inherent complexity of the topic. But the document does outline the broad steps you must take and offers guidelines on how to overcome common problems that other organizations have experienced.

SP Components

There are several basic components in a GFIPM SP that are noteworthy. Using a Shibboleth SP as an example, the SP components are illustrated in Figure 2 and discussed below. Other SP products may vary in their implementation details; however, the components described here will always be present in one form or another.

Figure 2: GFIPM Shibboleth Service Provider Structure

Note that the SP structure depicted in Figure 2 contains only the most basic components of a Shibboleth-based SP. In particular, the protected resource integration point in the diagram often contains custom code designed to provide an interface between legacy resources (which are not natively GFIPM-enabled and do not support access control and auditing based on GFIPM Metadata) and the GFIPM-enabled federation components.

Web Server

An SP enables basic federated identity management functionality for Web-based resources; therefore, it must contain a Web server. The Web server is responsible for serving sensitive Web-based resources to users who request them, subject to access controls and other usage policies that may exist. Resources may be served either directly or via a reverse-proxy-based architecture.

In addition to serving Web-based resources, the Web server is responsible for handling TLS encryption of HTTP traffic, including incoming SAML messages that are sent to the server from IDPs via the user's Web browser over HTTPS. The Web server component is typically integrated with SP core software module and relies on the SP core software module to handle basic SAML operations.

GFIPM participants using Shibboleth have successfully used two different Web servers at their SPs: Microsoft Internet Information Services (IIS) on Windows and Apache on Linux machines. At this time, no other Web servers or host operating systems have been used within GFIPM.

SP Core Software Module

The SP core software module integrates with the Web server and handles basic SAML-level operations within the SP. It is depicted in Figure 2 by a pair of blue boxes ("Shibboleth SP Web Server Plug-In" and "Shibboleth SP Standalone Daemon"). In the case of Shibboleth, it is implemented in C++ and consists of several components (a Web server extension module and a standalone daemon) that work in tandem.

The SP core software module must be integrated with Web-based resources via an integration point that allows it to protect them. The core module handles the processing of incoming SAML messages from IDPs, as well as the creation of outgoing SAML messages to IDPs. In addition, it manages the signing and encryption of all outgoing SAML messages, as well as signature verification and decryption of all incoming SAML messages. Interested readers may refer to [GFIPM U2S Profile] for normative details about the SAML protocols and messages used within the GFIPM federation; however, note that detailed knowledge of these protocols is not typically necessary for implementation of an SP using COTS or open-source software.

Protected Resource Integration Point

The protected resource integration point enables the SP to protect sensitive Web-based resources that are to be shared within the GFIPM federation. There are two ways in which the SP can be integrated with sensitive resources. Each method is discussed below.

• Integration Method 1: The first integration method involves the use of access control logic that is built into the SP software itself. When using this integration method, it is possible to construct simple access control policies that permit or deny access to specific URLs served by the Web server based on logic involving the SAML attribute values presented for a user. At the implementation level, this integration method is as simple as configuring the appropriate access control logic in the SP core software module via its UI or a configuration file. This integration method works only when the following two conditions apply: First, the granularity of access control for a resource protected in this manner is limited to static URLs. In other words, it is not possible to make access control decisions that depend on HTTP query variables (such as CGI parameters) using this technique. Second, the SAML attribute values used to make access control decisions in this manner must be relatively simple (e.g., limited to simple values such as a name or an e-mail address).
• Integration Method 2: The second integration method involves passing SAML attribute data directly from the SP core software module to a protected resource and allowing the resource itself to make its own access control decisions based on the data. SAML attribute data is passed to an application via the following mechanism. In the case of Shibboleth, the SP core software module inserts each SAML attribute value into an HTTP header that is passed to a resource at the same time that the resource receives notification of an HTTP/HTTPS request from the Web server. (At the implementation level, the resource typically receives all of its HTTP/HTTPS headers-including the headers constructed by the Shibboleth SP software-via environment values in its local environment.) After receiving the SAML attribute values, the resource can examine and process them as needed and make decisions accordingly.

SPs in NIEF typically use a combination of both integration methods, as follows. First, basic access to each SP is typically controlled using the SP's native access control facilities, with the following simple policy: 'A user may access resources on this SP if and only if he has authenticated with an IDP in the federation.' Then, the resources themselves (or an appropriate resource proxy implement a more fine-grained access control policy using SAML attribute values passed from the SP core software module. As previously mentioned, there are important considerations that influence the decision to serve a sensitive resource in the GFIPM federation directly or via a reverse proxy arrangement.

Optional GFIPM-Enabled Proxy/Portal Service

A protected resource can interact with the SP core software module within a Web server through its resource integration point. It is through this integration point that a resource can receive GFIPM user attributes for processing. Of course, GFIPM user attributes are not useful to a resource unless the resource has the ability to understand them, process them, and use them as needed for purposes such as user identification, access control, and auditing. A resource that has this ability is typically called a federation-enabled resource or a GFIPM-enabled resource.

Most of the resources that are currently useful to federation users tend to be legacy Web applications that contain dynamically generated Web pages, rather than simple static pages. And for most of these applications, it is not possible to modify the application's source code because of various business-level constraints.

Several of the participants in the GFIPM project act as umbrella organizations and manage networks containing resources that are owned by other organizations. For example, JNET manages access to data from the Pennsylvania Department of Corrections and Pennsylvania Department of Transportation; however, JNET does not own this data. This situation is likely to be the case for many other federation participants in the justice community.

If a resource is not already federation-enabled, and its source code cannot be modified for federation enablement, then the resource cannot exist natively within the GFIPM federation, so it must be made available to federation users via a proxy/portal service. Such a service exists to provide proxied access to a non-federation-enabled resource in a manner that allows the resource to exist in a GFIPM federation and be available to federation users without any modifications to the resource's source code or internal configuration. The remainder of this section describes the basic internal structure of a proxy/portal service.

Figure 3 shows the GFIPM Shibboleth SP structure depicted in Figure 2 but also illustrates how a GFIPM-Enabled Proxy/Portal Service fits into the SP architecture. Note that the proxy/portal service integrates directly with the Shibboleth SP middleware, providing a bridge between GFIPM-enabled service provider and
non-GFIPM-enabled legacy resources.

Figure 3: GFIPM Shibboleth Service Provider Structure With GFIPM-Enabled Proxy/Portal Service

A proxy/portal service typically includes the following logical components:

• Web Portal Service This is a federation-aware application that consumes GFIPM assertions and translates their content into access privileges for the proxied resources. Using these privileges, it defines network-level access control policies that are to be enforced by the reverse proxy service (see below). The Web Portal Service also presents a Web-based user interface for accessing the proxied resources. Finally, when necessary it may also handle the auditing of access attempts to the proxied resources.
• Reverse Proxy Service This is a network-level service that allows traffic to flow from a user's browser, through the SP's Web server, to protected resources. It enforces network-level access control based on instructions that it receives from the Web Portal Service. (The technical details concerning how access control policy is communicated from the Web Portal Service to the Reverse Proxy Service are implementation-dependent and outside the scope of this document.) Finally, when necessary, the Reverse Proxy Service handles authentication to protected resources in a manner that the resources understand.
• HTML Rewrite Engine One of the challenging but necessary aspects of reverse-proxying Web content is rewriting the URLs and URL fragments in the HTML, JavaScript, and other content served by the proxied resource, so that to the user's browser the content appears to have come directly from the proxy. This process typically involves modifying URLs within the HTML and JavaScript content so that they refer to the reverse proxy server rather than referring directly to the proxied resource.

GTRI has developed a low-cost solution for Service Providers who need to deploy a GFIPM-Enabled Proxy/Portal Service capability. The solution leverages a relatively inexpensive COTS reverse proxy product and HTML rewrite engine, called EZproxy, and also contains custom code. CISA is currently using this GTRI-developed solution to serve non-federation-enabled resources to GFIPM users. JNET has also developed its own GFIPM-Enabled proxy/portal capability using entirely custom code, with which it is serving non-federation-aware resources.

In addition, GTRI plans to develop a freely available "Service Provider in a Box" solution for future participants who wish to implement the proxy-based Service Provider model described above. At the time of this writing, these plans are still tentative.

Protected Resources

A protected resource is the actual sensitive content that needs to be protected by the SP infrastructure. As implied by the discussion in the previous two sections, all protected resources fall into two categories: GFIPM-enabled resources, which natively understand GFIPM metadata, and non-GFIPM-enabled resources that must be proxied. Most of the protected resources in NIEF at this time are not natively GFIPM-enabled, and it is expected that nearly all resources that will be added to NIEF in the future will also be non-GFIPM-enabled.

Because the purpose of the Service Provider is to make resources available to federation users, GTRI has developed federation enablement techniques through which a wide range of legacy resources in the law enforcement domain can be made available to federation users.

Writing an SP Test Plan

This section lists the necessary steps for a test plan for testing a new Service Provider in a test environment.

The new Service Provider should be deployed and tested in a test environment, followed by deployment and testing on an operational federation.

If you are also developing a new Identity Provider, you can deploy and test it at the same time that you deploy and test your Service Provider. Note that testing for interoperability between your own SP and IDP is insufficient in terms of full interoperability testing. Comprehensive interoperability testing requires that you test for interoperability between your SP and other organizations' IDPs, as well as between your IDP and other organizations' SPs.

Because there are a wide variety of possible test environments, with different Service Provider implementations and security requirements, it is not possible to give you a complete test plan for your SP. However, this section outlines the steps of the testing that should be performed, and you should be able to generate a test plan that is sufficient and specific to your organization.

Your test plan should address the following issues:

1. Test Goals: Your plan must address the following questions:
   1. Will you test individual modules (SP middleware, various resources, proxy/portal service, HTML content rewriting service, etc.)?
   2. Will you perform integration testing? If so, how will you test the interfaces between the SP's components (protected resource integration point, etc.)? For example, if you vary the attributes in a SAML assertion on one side of the interface, does the other side of the interface behave correctly with respect to your local access control policy?
   3. How will you perform interoperability testing of your SP? Keep in mind that the ultimate purpose of GFIPM interoperability testing is to determine whether your SP's access control logic is compatible with the GFIPM assertions that it receives from IDPs. To ensure broad test coverage of user attributes, you should use multiple test identities with varying attributes (user data, permissions, privileges, etc.) to ensure that your SP handles all conceivable cases properly. Also, be sure to notify your testing partners (the federation manager, IDP administrators, etc.) of your testing goals and plans.
   4. What are your organization's formal processes for acceptance testing? Be sure to notify your testing partners if you need results or other inputs from them.
2. Testing Schedule: Your testing schedule can be as simple as an e-mail asking/notifying your testing partners about the number of days you will need to communicate with them. Note that before testing begins, all required resources must be available.
3. Resource Logistics: You must identify all required resources, including all of the personnel, test machines, and network connections that will be required for testing.
   1. Test machines should be 100 percent available on test days.
   2. Identify and arrange for the required network connections (especially firewall and router configurations) well in advance of the test date. Connections (i.e., all specific port numbers) should also be tested. If necessary connections are denied, your local network administrator may need to open firewalls, which can take several weeks in some organizations.
   3. Notify all personnel who are required for testing well in advance of the testing date. This may include persons who are not part of your local organization.
4. Documented Testing Procedures: Generate a list of test cases, each of which must pass. Test cases should include SAML assertions that include the following:
   1. Only the minimum attributes
   2. An excessive number of attributes
   3. A reasonable number of attributes that allow access to some resources and not others. Carefully vary the values of attributes and check that the access permissions change as expected in accordance with the access control policy. It is strongly recommended that you create a user identity in your identity management system that is not a valid identity (such as a missing last name, missing e-mail, or malformed phone number), and perform tests to ensure that your SP behaves properly.
5. Responsibility for Carrying Out the Test Plan: Which person in your organization should execute the test plan? Experience has shown that a test plan works best when the person performing the testing is not the same person who implemented the software.

Deploying an SP in a Test Environment

This section presents steps required to deploy an SP in a test environment to ensure its connectivity and interoperability with GFIPM IDPs within the context of the GFIPM Trust Fabric.

Any new SP must be "connected" to a test environment by adding the SP to the test environment's trust fabric. The trust fabric update process consists of these steps:

1. Provide your SP's entity metadata to the federation manager.
2. The federation manager adds the new entity to the test environment trust fabric.
3. All participants in the test environment load the new test environment trust fabric into their IDPs and SPs.

You can test whether your SP's entry into the test environment's trust fabric has succeeded by verifying its SAML interoperability with other systems in the test environment.

The GFIPM Reference Federation is an excellent resource that is generally available for use as a test environment for GFIPM SPs. It contains a large number of useful and necessary resources for implementing and testing your service provider. These topics are covered more thoroughly in Appendix A.

Executing an SP Test Plan

Once you have written your test plan and implemented your Service Provider, you must execute the test plan.

While software issues almost always arise during testing, experience has shown that personnel scheduling problems and network configuration problems tend to cause the most delays during testing. The bottom line is that you must make sure all required personnel (especially required testing partners from other organizations) will be available as expected during the testing process, and that all machines used in the testing process have Internet connectivity on all required ports as needed.

Work through your test plan. Take thorough notes, and compile a test report to be distributed within your organization and to all testing partners.

Deploying an SP in an Operational Federation

This section presents steps required to deploy an SP on the operational federation to ensure its connection and interoperability to the GFIPM Trust Fabric.

During your deployment in the test environment, you were able to use all the test environment's resources. If you are now deploying your SP in the NIEF operational federation, here are the equivalent production resources that you can leverage:

• Publicly accessible information about NIEF is available at https://nief.gfipm.net/.
• The NIEF Trust Fabric document is located at https://nief.gfipm.net/trust-fabric/nief-trust-fabric.xml.

Note that there are no test IDPs or SPs in an operational federation such as NIEF. The operational federation contains live data, and test identities should never be used within it.

Any new SP must be "connected" to the NIEF federation (or your own GFIPM federation) by adding the SP to the federation's trust fabric. The trust fabric update process consists of these steps:

1. Provide your SP's entity metadata to the federation manager.
2. The federation manager adds the new entity to the federation trust fabric.
3. All participants load the new federation trust fabric into their IDPs and SPs.

Before or during your deployment, you must also fill out an Implementation Documentation Form for SP and submit it to your federation manager as part of the membership application process. A template of this form is available from your federation manager. It requests the following information.

• SP software platform details (OS, Web Server, SAML Software, etc.)
• GFIPM Metadata enablement of resources
• Network configuration notes

Your ability to test your SP in the operational federation will be limited because of the lack of test IDPs in the operational federation. According to the usage policies of most SPs in an operational federation, only real users using real identities (with valid user data, permissions, and privileges) are permitted to use (i.e., test) the production systems. Therefore, when executing your SP's Test Plan in the operational federation, you must perform the necessary tests using real users (from your organization and others). As before, write a Test Report to be distributed within your organization and to all testing partners.

To publicize your organization's resources to federation users, you must supply a list of your GFIPM-available resources to the federation manager, including the following information about each resource:

• Resource name
• Resource description
• How to use the resource
• Access control policy
• Usage scenarios

Extensive examples for the above information are available at http://nief.gfipm.net/ for each of the existing participants.