How to Implement a GFIPM Identity Provider

This article describes the steps necessary to implement a GFIPM Identity Provider (IDP). A GFIPM IDP collects information (typically from an existing identity store) about a local user and generates corresponding user metadata when a user attempts to connect to a local or remote GFIPM Service Provider.

Developing a GFIPM Information Sharing Plan for an IDP

During this process, you will accomplish the following:

1. Develop a list of federation resources to which you want your users to have access.
2. Identity your local users and collect all sources of information about them.
3. Design the metadata to describe your users.
4. Fill out a Local Attribute Mapping Form to map local attributes about your users into GFIPM metadata attributes.

If your organization has multiple attribute stores and/or authentication systems, you may need to consider implementing multiple IDPs at your site. Alternatively, you may wish to consider using a virtual LDAP product to consolidate your multiple sources of user data into one source. This situation may be especially applicable if the information in the attribute stores cannot be merged or different sets of users must stay with separate authentication or authorization systems. In the case of multiple IDPs at your site, the steps in this section should be performed for each IDP.

Discover Federation Resources

This section guides you through the process of discovering available resources in your federation and determining which of them may be of value to your organization's users. Additionally, you need to consider the future as your federation adds more Service Providers with more and more resources. You will want your users to have access to the appropriate resources in the future, preferably without having to add capabilities to your IDP. At the end of this section, you should have a list of access control policies for which your users need to qualify. This list will be used in subsequent sections to help you implement an IDP that can assert the appropriate metadata.

The following steps will help you accomplish the above goals:

1. Survey the current landscape of available federation resources.
2. Determine which existing resources would be of value to your users. Also consider what other future resources you might want for your users and what the access requirements for those resources might be.
3. Review the access control polices for the resources you would like to use.

To explain these concepts and help you put them into action, resources in the NIEF federation are used as examples throughout this section.

Survey Federation Resources

This section describes how to examine the list of federation resources and generate a list of resources that you want your users to access.

To allow prospective federation members to determine what members' resources would be of value to their users, the federation should maintain a registry of existing resources, including a description and access control policy for each resource. The information should be available from your federation manager.

For NIEF, the resource list is available at http://gfipm.net/users/ with a section for each current federation member.

The following are a few examples of NIEF resources and their access control policies with implementation guidelines and explanations.

Resource Example 1

As can be seen from the resource list, each resource has an access control policy. The policy may be as simple as for the Arizona Counter Terrorism Information Center resource, provided by the CISAnet portal:

Access Control Policy

Any user with a valid federation login may access this resource. In addition, sufficient audit data is required for all users.

In the above requirement, a "valid federation login" refers to a user who is able to log in to an IDP of any NIEF federation member. In effect, this is the absolute minimum requirement possible for being granted access to a resource. Some portals provide useful public resources in this manner and the users gain from seeing a collection of such resources in one location, but such public resources do not provide law enforcement data.

Because some Service Providers (SPs) may actually require that a user have permission to view public resources, we recommend that IDPs assert the "Public Data Self Search Home Privilege Indicator" in the user's metadata. Service Providers are free to assume that all users have public permission but are not required to and may not implement such an assumption.

The "sufficient audit data" includes information that can be used to uniquely identify a user and is stored in the audit log files of a service provider, portal, and/or application.

Resource Example 2

Most resources have more complex policies; for example, the resource Texas Criminal Law Enforcement Online (CLEO) provided by the CISAnet Service Provider:

Access Control Policy

Any user who is a sworn law enforcement officer may access this resource. In addition, sufficient audit data is required for all users.

The definition of a sworn law enforcement officer (SLEO) is as follows. He/she is:

• A full-time employee of a state-recognized law enforcement agency.
• Authorized to make an arrest (has the authority).
• Certified by a state certifying authority (e.g., Peace Officer Standards and Training [POST]), or equivalent.

OR

• A full-time employee of a state-recognized law enforcement agency, acting on behalf of a SLEO, in performance of his or her assigned duties.

An IDP indicates that a user is a sworn law enforcement officer by asserting the "Sworn Law Enforcement Officer Indicator" as "true" in that user's metadata. Many of the more useful resources available require that the user be a sworn law enforcement officer, so you as the IDP developer are strongly urged to implement the necessary code to determine whether your user qualifies.

The requirement for the audit data is described in example 1 above.

Resource Example 3

Other resources may have very restrictive access policies, as demonstrated by the Texas Criminal Law Enforcement Reporting and Information System (CLERIS) resource:

• Be a sworn law enforcement officer.
• Have an agency ORI code.
• Have either the criminal investigative home data search privilege OR a combination of the criminal intelligence home data search privilege and 28 CFR certification.
• Identity-proofing assurance is NIST level 4, and electronic identity assurance is at least NIST level 3.
• Provide sufficient audit data.

The IDP must assert the sworn law enforcement officer indicator as demonstrated in example 2 above.

To access CLERIS, a user must have an ORI code, which must be asserted by the user's IDP in the user's metadata in the attribute "Employer ORI." Many resources available from GFIPM participants require an ORI code, so IDP developers are strongly urged to supply them.

Further, a user's home IDP must assert the attribute "Criminal Investigative Data Self Search Home Privilege Indicator" or must assert the attributes "Criminal Intelligence Data Self Search Home Privilege Indicator" and "28 CFR Privilege Indicator."

The requirement for sufficient identity proofing (asserted as the attribute "Identity Proofing Assurance Level Code") refers to the level of assurance that the person assigned this electronic identity is actually the user. The levels of assurance vary from no requirements to appearing in person with certain photo IDs or supplying certain identification assurances from a remote location that are inspected or validated to a specified degree by the issuing authority.

The requirement for electronic identity authentication assurance level (asserted as the attribute "Electronic Authentication Assurance Level Code") refers to the level of confidence in the asserted digital identity. The asserted level depends on the IDP's authentication mechanism, which ranges from simple and relatively insecure methods (such as username/password authentication) to more secure methods (such as two-factor authentication with a hardware crypto token). The requirement for the audit data is described in example 1 above.

Determine Valuable Resources

At this point, you should have a list of resources for your users. After finishing the survey of federation resources in the previous section, you should have a feel for the types of resources that you might add to that list if they become available in the future.

If your federation plans to add new members, or if prospective members are already in the process of joining your federation, you may wish to inquire about the resources that may soon be added to the federation via the addition of those new federation members. If you determine that these additional resources would be valuable for your users, you may wish to plan ahead for asserting their required attributes even before they come online in the federation.

For example, NIEF is a relatively new federation, with few members at this time. However, as of this writing, several new members are in the process of submitting their application packages, so it is likely that NIEF will increase significantly in size in the near future. A new IDP implementer should contact the NIEF federation manager for advice on expected new members and resources, so that the IDP's users can gain access to these new resources without the implementer having to add support for more attributes at a later date.

For example, on the CISAnet Service Provider, you saw that several resources (such as NM Law Enforcement Information Network with Corrections or NM Complete Arrest Information) require the Criminal History privilege. Suppose you determine that these would be useful resources for your users, except that your users are not necessarily interested in the New Mexico data but would be interested in other states' similar resources. You should add "Criminal History Resources" to your list of desired resources. Further, you see that some of these same resources also require the NCIC Criminal History Certification, so you add "NCIC Criminal History Certification Resources" to your list of desired resources.

Review Access Control Policies

Next, review your list of desired resources and determine which privileges, certifications, indicators, and electronic identifications you must support in your IDP to allow your users to access those resources. This list represents the privileges, certifications, and indicators that you would like to assert for your users, but not necessarily those that you can assert. At this point, it is better to build an over-inclusive list than a list that may be missing some desired permissions.

After you identify your users' needs from a GFIPM perspective, you can design the GFIPM user metadata to be built by your IDP.

Identify Local Users

This section guides you through a process to collect all known information about your organization's users and collect it for use as a basis for a GFIPM Identity Provider (IDP).

To implement a GFIPM IDP, you must gather existing sources of information about your local users. These sources may consist of a user directory, a database system, applications that manage user identities, and organizational policies and other documents.

A user directory may be implemented as LDAP or Active Directory or some other
in-house or commercial system. A database may be implemented as a system such as Oracle or SQL Server or one of many other commercial or open-source systems. Other sources may include user applications such as criminal information systems, case management systems, or records management systems. These systems will then serve as the providers of local user information to the federation member's IDP.

Each source about local users should provide information such as the following:

• Name, address, phone number
• E-mail address
• Unique user ID
• Home organization, employer, assignment, job classification
• Certifications and clearances
• Permissions and privileges
• Electronic or digital identity

In addition, there may be other, more indirect sources of information about users. Organizations typically have documented security policies. Users may also be required to sign user agreements, which typically specify levels of training or qualifications for the user. These may specify conditions of employment such as background checks, user qualifications, certifications, or security clearances.

Three specific instances of these types of documents include the following:

1. Local Security Policy Document: A document describing the security policy that is currently in place within your organization.
2. Local User Agreement Document: A document describing the terms and conditions to which your users must agree as a prerequisite for using an electronic identity issued by your organization.
3. Local User Vetting Policies and Procedures Document: A document describing the user vetting policies and procedures that are currently in place within your organization.

Implicit or derived information from the above documents can add to the knowledge base about your users, either individually or as a group. At this point, you should collect these documents from your organization and use them as a basis for additional knowledge about your users. In addition to serving as sources of information about users, the three documents listed above will be used during your organization's federation application process (see [GFIPM OPP]).

An example of information derived from a security policy is the following derivation rule used by CISAnet, which is a federation member in NIEF:

All CISAnet users have 28 CFR training as a documented organizational policy. These users have the CISAnet Criminal Intelligence permission. While the 28 CFR training information is not stored in the local identity management system, the policy is used as a basis for the CISAnet IDP to assert the "28 CFR Privilege Indicator" in the GFIPM user metadata. Furthermore, the CISAnet IDP also asserts the attribute "Criminal Intelligence Data Self Search Home Privilege Indicator" for its users.

After you finish this section, your GFIPM Information Sharing Plan should include details about all your sources of user information and also document details about which specific information is available for users from each source. This information will eventually appear in your Local Attribute Mapping Form.

Design User Metadata

This section presents instructions on how your organization should design its user metadata, based on your list of desired federation resources and the information about your users.

The GFIPM Metadata Specification includes a standard set of informational attributes that can be asserted for a user. Example attributes are a user's name, phone number, title, permissions, etc. These attributes are collected by an IDP, assembled into a SAML assertion, and securely transmitted to an SP on behalf of a user.

Your federation manager should provide you with advice on which metadata attributes are required or recommended for assertion by IDPs in your federation.

Taking into account the GFIPM definition of each metadata attribute you want to assert, determine whether and how you can truthfully assert it for your users based on your locally available user information. Assertions can be based either on explicit local attribute data (stored in a user repository) or on implicit assumptions about users based on local policies.

You may encounter a situation in which you want to assert an attribute but are unable to assert it based on locally available information. In this case, you have two choices-do not assert it or collect and store the data necessary to assert it.

Remember that the basis for asserting each user attribute must be documented in the Local Attribute Mapping Form.

At the end of this process, you should have a list of GFIPM metadata attributes that your IDP will assert, along with the precise GFIPM definition for each of those attributes.

Each metadata attribute that your IDP is able to assert must be asserted with a valid value in the SAML assertion. The values must be either extracted from one of your local data sources or validly derived for each user. In addition, how you assert these attributes (i.e., the data source or reasoning you used) must be documented in your Local Attribute Mapping Form.

As defined by your federation manager, required metadata attributes are mandatory based on their use to uniquely identify a user and to audit transactions. Your IDP must assert these metadata attributes.

Strongly recommended attributes are those attributes used by many Service Providers or resources in their access control policies. Assertion of these attributes typically leads to more data access opportunities for users. Your IDP should assert these metadata attributes if possible.

The other listed attributes are recommended, which means that useful resources tend to use them in their access control policies. Your IDP should assert these metadata attributes if possible.

Fill Out a Local Attribute Mapping Form

This section will help you fill out a Local Attribute Mapping Form to map local attributes about your users into GFIPM metadata attributes. The Local Attribute Mapping Form for your IDP is later used as part of your request for federation membership.

The Local Attribute Mapping Form is briefly described in the Operational Policies and Procedures document [GFIPM OPP]:

A document describing how the organization plans to map its local policies and locally stored user attributes into attributes conforming to the GFIPM Metadata standard.

When the federation manager reviews your application package, he or she will provide a copy of your Local Attribute Mapping Form (for an IDP) to all existing members for review and comment.

The Local Attribute Mapping Form should be written as a spreadsheet (i.e., in 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 IDP name in the file name.

Table 2 contains an example of the design of the spreadsheet, including the headers followed by five rows describing attribute mappings. Note that these examples are from different members, so their derivations are not related to each other.

GFIPM Attribute Map - Identity Provider Name: <Your Organization>
Semantic Intent of Mapping	Mapping Rule From Local Attribute/Policy to GFIPM Metadata
	GFIPM Metadata Attribute	Mapping Method	Local Source Attribute
First name of user	Given Name	Calculated from Local Attribute CN (Common Name) from ABCD Directory	Take substring to the first space in CN starting from the left.
The unique federation-wide identifier for this user	Federation ID	Fixed text plus Local Attribute (e-mail address) from the ABCD Directory for this user	"GFIPM:IDP:ABCD:USER:" + e-mail
ABCD does not have an attribute to indicate whether a user is a public safety officer. This derivation should yield a reliable indicator if the user is a public safety officer or working at the behest of one.	Public Safety Officer Indicator	Derived from Local Attributes in Directory	"true" if (departmentNumber contains 'Police' OR 'Patrol' OR 'Sheriff' OR '911') OR (title contains 'Officer' OR 'OFFICER' OR 'Dispatch' OR 'Sheriff' OR 'District' OR 'Patrol' OR 'Lieutenant' OR 'Sergeant') OR (postalAddress = 'police')
Derive if a user is legitimately a sworn law enforcement officer even though ABCD does not store this information in our directory	Sworn Law Enforcement Officer Indicator	Derived from Local Attribute Criminal Intelligence permission	All our SLEO users who go through 28 CFR training are given the Criminal Intelligence permission in our directory. If a user has this permission, our IDP will assert this indicator.
The contact e-mail for questions about ABCD or the identity information in the ABCD SAML assertion. This is the ABCD help desk e-mail address.	Identity Provider Organization Point of Contact E-mail Address Text	Fixed text	techsupport@abcd.gov

Table 2: Example of Local Attribute Mapping Form

In the above spreadsheet, you must have a row for every GFIPM Metadata attribute that your IDP asserts, explaining the source of the value and how you plan to map from the source to the GFIPM attribute.

If you would like additional examples of a Local Attribute Mapping Form, please contact gfipm-support@lists.gatech.edu to request them.

At this point, you should have completed the GFIPM Information Sharing Plan and the Local Attribute 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 should be collected or generated during the IDP implementation process. The authoritative document for the process of submitting a membership request in NIEF is the Operational Policies and Procedures Document [GFIPM OPP].

The membership process is defined in [GFIPM OPP]. The process follows the following four phases:

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

While going through the IDP implementation process, you should either collect or produce the following membership documents:

1. Authority-to-Operate Document: A document attesting to the organization's authority to operate as an identity provider and provide access to the federation for the organization's users. It 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 User Vetting Policies and Procedures Document: A document describing the user vetting policies and procedures that are currently in place within your organization. This document should already exist within your organization.
5. Local Attribute Mapping Form for IDP: A document describing how the organization plans to map its local policies and locally stored user attributes into attributes conforming to the GFIPM Metadata standard [GFIPM Metadata].
6. Implementation Documentation Form for IDP: 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 document. For more complete documentation about the membership application and technical onboarding process for a GFIPM federation, please see the GFIPM Operational Policies and Procedures Guideline [GFIPM OPP].

Choosing an IDP Product

This section lists the requirements for products that may be considered for a GFIPM IDP. It also briefly describes the IDP products for which GFIPM implementers currently have some amount of knowledge and implementation experience.

As you work through the process of choosing an IDP product, consider which product best meets your organization's needs, and keep in mind that the best product for you may not necessarily be included in this document. For those organizations that have an existing enterprise identity management platform, the best choice may be to implement a GFIPM IDP via that existing platform - especially if the existing identity management platform conforms to the GFIPM IDP technical requirements (listed below).

An Identity Provider (IDP) is responsible for authenticating an end user and asserting a SAML assertion for that user in a trusted fashion to Service Providers. When a user attempts to access a Service Provider, the user's IDP collects local attribute information about the user and uses it to generate a SAML assertion for the user.

A GFIPM IDP must meet the following minimum requirements:

1. It must conform to the SAML 2.0 Web Single Sign-On (SSO) Profile [SAML2].
2. It must support SP-initiated Web Browser SSO.
3. It must be compliant with the IDP requirements in [GFIPM U2S Profile].

Typically, an IDP consists of several components, including:

• User authentication
• Local user repository
• SAML assertion generation

An IDP product may address one or more of these components, but in any case, it must perform the SAML assertion generation. It is likely that your organization already supports several of these components, including user authentication and a local user repository. Any IDP product must support interfaces to these existing systems.

While an IDP generates a SAML assertion that provides attributes about a user, an SP handles 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 protocol through which this communication occurs in GFIPM is the Security Assertion Markup Language [SAML2].

SAML is a product of the OASIS Security Services Technical Committee (SSTC). It is an XML-based framework for communicating user authentication, entitlement, and attribute information. 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 also be an application or system) to other entities, such as a partner company or another enterprise application.

Any IDP product chosen for a GFPIM federation must be SAML 2.0 compatible. The product must also have support for looking up GFIPM Metadata attributes in a local data source, so they can be assembled into a SAML assertion.

The following is a non-exhaustive list of products that provide SAML-based identity provider capabilities. You should evaluate these and other products to determine which best meet your needs within your budget.

Shibboleth IDP

Shibboleth is a standards-based, freely available 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 2.0. It is being used by at least one participant in GFIPM.

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 product Web page is at https://spaces.internet2.edu/display/SHIB2.

Ping Identity PingFederate IDP

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. PingFederate is SAML 2.0-compatible. Note that the PingFederate Internet Identity Security Platform can act as both an IDP and an SP.

CA Federation Manager IDP

Federation Manager is a commercial product marketed by CA (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 IDP

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 IDP

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

Implementing a GFIPM IDP

This section provides an overview of the logical structure of a GFIPM IDP and also guides the reader through the process of implementing a GFIPM IDP at a high level. Note that it is possible for implementers to become confused about the difference between a GFIPM IDP and an existing local identity management system. A GFIPM IDP is a secure service that produces a SAML assertion for a user. The user information in the SAML assertion should be based on your organization's local identity management system, which may be a directory, a database, or another application to manage your user identities. GFIPM does not dictate how your user identities are managed, nor does it require modification to your identity management system beyond establishing a means to interface your GFIPM IDP to it.

After choosing an appropriate IDP product, the next step is implementing a GFIPM IDP using it. While this document cannot lead an implementer through all the details of installing a product and interfacing it to your organization's identity management system, it does outline broad steps and offer guidelines on how to overcome specific IDP implementation issues that other GFIPM participant organizations have experienced.

IDP Components

An IDP consists of several logical components. Using a Shibboleth IDP as an example, the IDP components are illustrated in Figure 1 and discussed below. Other IDP products vary in their implementation details; however, all the components described here need to be present in some form for any IDP product.

Figure 1: GFIPM Shibboleth Identity Provider Structure

IDP Core Software Module

The IDP software module, depicted by the blue box ("Shibboleth IDP Middleware") in Figure 1, consists of a set of interfaces, called integration points, which must be connected to other system components for the IDP to work. In the case of Shibboleth, it is implemented as a Java servlet and runs within a Web servlet container.

The IDP core software module handles the processing of incoming SAML messages from SPs, as well as the creation of outgoing SAML messages to SPs. In addition, it manages signing and encryption of all outgoing SAML messages, as well as signature verification and decryption of all incoming SAML messages. In the case of Shibboleth, the Web servlet container in which the software runs is responsible for handling the IDP's connection-level (TLS) encryption needs. 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 IDP using COTS or open-source software.

Web Servlet Container

A Web servlet container is often required on a GFIPM IDP to run the IDP core software module. (It is required in the case of Shibboleth.) Many such Web servlet containers are available for use, but GFIPM participants have chosen to use the freely available Tomcat [Tomcat] open-source servlet container. Tomcat was chosen for several reasons. First, Tomcat is fully compatible with the Shibboleth IDP middleware; in other words, it runs the Shibboleth code without any problems. Second, Tomcat supports connection-level encryption using both SSL and TLS. Third, Tomcat supports client certificate authentication of browsers with support for certificate revocation lists (CRLs). Fourth, Tomcat runs on both of the major operating system platforms (Microsoft Windows and Red Hat Enterprise Linux) that GFIPM participants use.

IDP Integration Points

Implementing an IDP in a federation requires that two integration issues be addressed. The first of these issues involves the integration of the IDP with the local site's user authentication system (the single sign-on integration point), and the other involves connecting the IDP to the local site's attribute repository (the attribute authority integration point).

At the single sign-on integration point, the user authentication system can be a username/password authentication system (though this form of authentication does not provide enough assurance for the use of most federation resources), a token-based authentication system, a PKI-based client certificate authentication system, or another two-factor authentication system. By having chosen Tomcat as the Web servlet container, we automatically gained support for client certificate authentication of browsers with support for certificate revocation lists (CRLs).

At the attribute authority integration point, the IDP should be connected to the existing attribute data store, which is your local identity management system (such as a LDAP repository).

Web Single Sign-On System

The Web single sign-on (SSO) system integrates with the IDP core software module via an SSO integration point and provides the basis for the IDP core software module to generate SAML authentication statements about users. To realize the single sign-on benefit of federated identity management, an SSO system must already exist and must already be used to authenticate your users for other purposes.

Attribute Data Store

The attribute data store integrates with the IDP core software module via an attribute authority integration point. It provides a source of trusted data about users that can be used to construct SAML assertions. Any component that acts as an attribute data store is essentially a database. There are virtually no limitations on the attribute data store in terms of how it stores attributes; however, in the case of Shibboleth, it must store attributes in a fashion that allows for attribute queries based on a user ID or some other key that can be understood by the Shibboleth IDP and maps uniquely to a specific user. Typically, an organization will want to connect an IDP to an existing user attribute repository-often an LDAP repository or an Active Directory database. It is also possible to use an ODBC or SQL database, a flat file on the local machine's file system, or any other repository, via custom Java code. But these cases are rare. The most common implementation scenario involves connecting an IDP directly to a local LDAP or Active Directory server.

Writing an IDP Test Plan

This section describes how to write a plan for testing a new IDP in a test environment such as the GFIPM Reference Federation.

The new Identity Provider should be first deployed and tested in a test environment, followed by deployment and testing in the operational federation.

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

There are a wide variety of possible test environments, each having different IDP implementations and security requirements. It is therefore not possible for this guide to provide you with a "complete" test plan for your IDP. But this section outlines the basic testing steps that you should perform, regardless of your test environment. Based on these steps, 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 (IDP middleware, SSO system, attribute data store, assertion generator, etc.)?
   2. Will you perform integration testing? If so, how will you test the interfaces between the IDP's components (single sign-on integration point, attribute authority integration point, etc.)? For example, if you vary the data on one side of the interface, does the information on the other side reflect the change correctly?
   3. How will you perform interoperability testing of your IDP? Keep in mind that the ultimate purpose of GFIPM interoperability testing is to determine whether your IDP's user attributes are compatible with the SPs that consume and use them. To ensure broad test coverage of user attributes, you should create multiple test identities with varying attributes (user data, permissions, privileges, etc.) to ensure that user attributes for your local identities are correctly translated into the appropriate GFIPM user attributes. Also, be sure to notify your testing partners (the federation manager, SP 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 of the 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. It is strongly recommended that you create a user identity in your identity management system that is not a valid identity (such as missing last name, missing e-mail, or malformed phone number) and perform tests to ensure that your IDP behaves properly when dealing with it.
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 IDP in a Test Environment

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

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

1. Provide your IDP's entity metadata to your federation manager (or the organization that manages the test environment you will use).
2. The federation manager adds the new entity to the trust fabric file.
3. All participants load the new trust fabric file into their IDPs and SPs.

You can test whether your IDP's entry into the test environment's trust fabric has succeeded by verifying its SAML interoperability with other members of the test environment.

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

Executing an IDP Test Plan

After you have written your test plan and implemented your Identity 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 IDP in an Operational Federation

This section presents steps required to deploy an IDP in 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 IDP 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 IDP must be "connected" to NIEF (or your own operational GFIPM federation) by adding the IDP to the federation's trust fabric. The trust fabric update process consists of these steps:

1. Provide your IDP'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 your IDP and submit it to the federation manager as part of the membership application process. A template of this form is available from the federation manager. The form requests the following information:

• IDP software platform details (OS, Web server, SAML software)
• User authentication endpoint details
• User attribute endpoint details
• Network configuration notes

Your ability to test your IDP in the operational federation will be limited because of the lack of test SPs 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 operational systems. Therefore, when executing your IDP's test plan in the operational federation, you must perform the necessary tests with real users (from your organization and others). As before, write a test report to be distributed within your organization and to all testing partners.