GFIPM Enablement of Resources

This page describes common methods of enabling applications to be used with a GFIPM Service Provider. Distinctions are made between new and legacy applications and how their enablement may differ.

Introduction

From the user's perspective, the implementer's primary job is to make a large set of resources available on the Service Provider. From the implementer's perspective, the implementer's primary job is to retain and enforce the usage requirements of his resources; in other words, ensuring that access control and security requirements are met by all users. Techniques exist through which a wide range of legacy resources in the law enforcement domain can be made available to federation users. The process of making a resource available to federation users is called federation enablement.

As a federation grows, resource owners will look to the GFIPM model to help them realize the following value propositions of federated identity and privilege management.

• Achieve resource sharing with a large base of established users and partners who would normally not have access to their resources, while keeping costs low.
• Provide a simplified and improved user experience (via single-sign-on access to all federation resources, subject to access control policies).
• Provide better security and privacy protection for users' personal data (via the reduction or elimination of redundant data capture and storage processes).

But achieving federation enablement for a wide range of legacy resources can be challenging in that they can be very diverse in many aspects, including application architecture, implementation platforms and vendor products, type and structure of resource, application functionality, support model, security and access policies, etc. Many insights and lessons about federation enablement of resources have been gained from current federation members during the process of federation-enabling several existing resources.

Applications and resources tend to have usage requirements that must be met by all of their users. Most usage requirements fall into the following categories:

• Terms of Use: The application may require that a user agree to specific terms of use prior to using it.
• Provisioning: The application may require that a user register a local account with it before using it.
• Inter-Session Persistence: The application may need to maintain status about the user from one session to another.
• Identification: The application may need to know the user's identity at all times while the user is using it.
• Access Control: The application may impose certain access restrictions based on some combination of the user's rank, certifications, role, or some other important personal characteristics.
• Auditing: The application may log all actions performed by a user in an audit log for review, compliance, etc.
• Personalization: The application may need to maintain miscellaneous personal data about a user for the purpose of delivering certain features. For example, locality information would help the application deliver a list of alerts or bulletins that specifically pertain to a user's region or locality.

One of the fundamental tenets of the GFIPM concept is that resource owners must be able to maintain control over the usage requirements of their resources within the federation and are not forced to modify the requirements in a manner they find unacceptable. GFIPM allows a wide range of existing resources and applications to be federation-enabled and made available to federation users in a manner that fulfills the usage requirements of those applications.

The GFIPM concept provides many valuable tools that help to simplify federation enablement of resources, while still allowing those resources to meet their usage requirements.

• Federation-wide policy-level agreements and memoranda of understanding can form the basis of interagency trust, which can be layered with additional bilateral or community agreements as required.
• The basic SAML-based infrastructure provides a standard means of authentication/identification of users and the convenience of SSO.
• The GFIPM metadata provides detailed personal information about individual federation users, including identification, contact information, affiliations, memberships, certifications, and basic data access privileges within the user's home organization. This information can be trusted because it comes to the resource from a secure, trustworthy, authoritative source: the user's IDP.

The following information will help federation implementers better understand the basic federation enablement options that are available to them for various categories of resources.

Resource Integration Profiles

The following resource integration profiles are based on common categories of resources and applications. Their purpose is to help resource owners better understand the level of effort required to federation-enable specific types of resources. Note that a specific resource may or may not fit neatly into a specific integration profile. This section does not necessarily describe an exhaustive set of resource classes, but rather provides enough detail about the critical differences between resources to illuminate the important issues that must be addressed when federation-enabling them.

Profile 1: Read-Only Content Without Individual User Accounts

A resource in Profile 1 has the following characteristics:

• It is used for dissemination of information.
• It does not require a unique pre-provisioned user account for each user.
• It may require the user's identity and contact information for auditing purposes.
• It requires some basic information about the user for access control.
• It does not require personalization data.
• It has no persistence requirement.

Profile 2: Resource With Individual User Accounts and Dynamic Provisioning

A resource in Profile 2 has the following characteristics:

• Its provisioning requirement can be met by GFIPM Metadata and leverage the IDP user vetting without the need for any additional out-of-band communication or user vetting during the provisioning process.
• It requires the user's identity and contact information for auditing purposes.
• It requires information about the user at account provisioning time for provisioning the account's access control permissions.
• It may require personalization data.
• It has a requirement for persistence of user account information between sessions.

Profile 3: Resource With Individual User Accounts and Pre-Provisioning

A resource in Profile 3 has the following characteristics:

• It requires a unique pre-provisioned user account for each user.
• Its provisioning requirement cannot be met by GFIPM Metadata and IDP vetting alone, since it requires out-of-band communication to facilitate a direct relationship with the user during the provisioning process. However, GFIPM can provide single sign-on functionality with an account linking capability for it after the provisioning process is complete.
• It requires the user's identity and contact information for auditing purposes.
• It requires information about the user at account provisioning time for provisioning the account's access control permissions.
• It may require personalization data.
• It has a requirement for persistence of user account information between sessions.

The next section discusses the actual techniques that can be used for federation enablement of resources that fit these integration profiles.

Resource Integration Techniques

The following resource integration profiles are based on common categories of resources and applications. Their purpose is to help resource owners better understand the level of effort required to federation-enable specific types of resources. Note that a specific resource may or may not fit neatly into a specific integration profile. The intent of this section is not to prescribe an exhaustive set of resource integration techniques, but rather to provide enough detail about the critical differences between the techniques to illuminate the important issues that must be addressed when considering their use.

Technique 1: GFIPM-Aware Reverse Proxy and HTML Rewriting Service with No Secondary Authorization

Integration Technique 1 works best for a resource that meets the following criteria:

1. It is not natively GFIPM-aware.
2. It does not require local user accounts or user authentication as a prerequisite to access.
3. It does not require or have any notion of intersession persistence or personalization.
4. It cannot be modified at the source code level because of business/technical impracticalities.

In this integration technique, access to the resource is provided for federation members via network configuration by a reverse proxy service that is GFIPM-aware. Also, the proxy service must implement access control and auditing if they are required by the application.

Technique 2: GFIPM-Aware Reverse Proxy and HTML Rewriting Service with Secondary Authorization

Integration Technique 2 applies to any resource that meets the following criteria:

1. It is not natively GFIPM-aware.
2. It does require local user accounts for access.
3. It cannot be modified at the source code level because of business/technical impracticalities.
4. Its access policy may require that each federated user have a unique account, or it may allow multiple users to share a group account.
5. It may or may not require intersession persistence for an account, and it may or may not have any personalization requirements.

In this integration technique, access to the resource is provided for federation members via a reverse proxy architecture in which the proxy maps each GFIPM user into a corresponding user account for the proxied resource. The mapping from GFIPM user to back-end resource account may be many-to-one (using local accounts at the resource as group accounts for GFIPM users) or one-to-one (using individual accounts). The proxy must authenticate the user to the proxied resource using the appropriate account.

If access to the resource is to be permitted via group accounts, a typical configuration would consist of relatively few local accounts on the resource (e.g., the number of group accounts in the application), with each account corresponding to an access class, group, or role that would be used by many federation users. In this configuration, since the resource knows only group accounts, it has no way to know which specific GFIPM user is accessing it at any given time. Therefore, to provide end-to-end auditing, it is necessary to combine the proxy's audit logs with the resource's audit logs. Two NIEF participants have successfully enabled federation resources using group accounts in this manner.

If access to the resource requires each GFIPM user to have a unique back-end account with the resource, it is necessary to provision individual user accounts for access. The most elegant approach to solving this problem is to allow user accounts to be provisioned via an account sign-up page on the back-end resource, and configure the proxy to populate the resource's account provisioning (sign-up) page with GFIPM user attribute data extracted from a SAML assertion. If this type of dynamic account provisioning is not possible (for either business or technical reasons), the proxy can act as an account-linking bridge between GFIPM federated user accounts and local back-end accounts that have been pre-provisioned out-of-band.

In either scenario, the proxy must somehow know how to map each GFIPM user ID to a back-end user ID on the resource. This may be accomplished in several ways, but the most straightforward technique is for the proxy to maintain a database or map from one domain to the other. In some cases where accounts follow a regular form, a set of rules or algorithmic mapping may be possible.

Technique 3: Native GFIPM Enablement

If it is possible and practical to modify the source code of a resource during the federation enablement process, the resource can be configured so it natively understands GFIPM metadata and can exist in the GFIPM environment without the aid of a proxy.

If the resource is a newly developed application, it may be advantageous to design and build the application such that it fundamentally understands GFIPM Metadata as its primary internal model for fulfilling its requirements related to identifying the user, enforcing access control rules, and auditing access.

But if the application already exists, it may be necessary to take an alternate approach and develop a GFIPM-aware module that exists within the application and serves to translate information from GFIPM metadata into the native user model that the application uses.

Issues related to account provisioning (dynamic or out-of-band) are the same for this technique as they are in the discussion above for Technique 2.

Profiles and Techniques for Existing Resources

To provide a more concrete perspective on the discussion about integration profiles and integration techniques in the previous two sections, this section contains summary information about how resources currently in the federation were federation-enabled.

The table below lists resources currently in the NIEF federation, along with their integration profiles and the integration technique used to integrate those profiles with the federation. It is important to note that while the table provides some insight into the breakdown of GFIPM resources for federation enablement purposes, it is not necessarily representative of the broader set of information sharing resources in the justice community.

For federation growth and outreach purposes, it is important that the federation gain some insight into how well the current set of integration techniques can accommodate the broad range of resources that are potentially applicable to GFIPM. Current and future implementers should be able to add their experience to the enablement knowledge base.

	Resource Name	Integration Profile	Integration Technique
CISA	Arizona Counter-Terrorism Information Center (ACTIC)	1	1
	Arizona Sex Offender Information Center	1	1
	Arizona Amber Alert	1	1
	Georgia Bureau of Investigation Sex Offender Registry	1	1
	Oklahoma State Bureau of Investigation Officer Safety Bulletin	3	2
	Texas Criminal Law Enforcement Online (CLEO)	3	2
	California Joint Regional Information Exchange System (JRIES)	3	2
	CISAnet Federated Query Tool	2	3
JNET	Pennsylvania Department of Corrections Intake/Exit Photos	3	2
	Pennsylvania Arrest Warrants Outstanding for Parolees who Failed to Report (Absconders)	3	2
	Pennsylvania State Prisoner Locator	3	2
	Pennsylvania Criminal Trial Case Information	3	2
	Pennsylvania Arrest Warrants Outstanding for Failure to Pay Child Support	3	2
	Pennsylvania Amber Alert	3	2
	GFIPM Lessons Learned	1	3
RISS	HSIN Counterterrorism Briefs, Reports, and Documents	1	3
	RISS Counterterrorism Briefs, Reports, and Documents	1	3

Integration Profiles and Integration Techniques for Resources in NIEF