How to Implement a GFIPM Service Provider

From GFIPM Implementation Wiki
Jump to: navigation, search
Main Page | Next


This article lists the steps necessary to implement a GFIPM Service Provider (SP):

  1. Develop a GFIPM Information Sharing Plan for a Service Provider
  2. Submit a Request for Federation Membership as a Service Provider
  3. Choose an SP Product
  4. Implement a GFIPM SP



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:

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.


Main Page | Next
Retrieved from "https://impl.gfipm.net/mwiki/index.php?title=How_to_Implement_a_GFIPM_Service_Provider&oldid=539"