+-----------+-----------------------------------------+---------------+
| ![](m     | **Global Federated Identity and         | ![](media/im  |
| edia/imag | Privilege Management:\                  | age2.jpeg){wi |
| e1.png){w | **A Global Concept                      | dth="1.645833 |
| idth="1.0 |                                         | 3333333333in" |
| 173611111 | Activities and Progress Report          | heig          |
| 111112in" |                                         | ht="1.6458333 |
| hei       | Version 1.0                             | 333333333in"} |
| ght="1.01 |                                         |               |
| 736111111 |                                         |               |
| 11112in"} |                                         |               |
+-----------+-----------------------------------------+---------------+

Global Justice Information Sharing Initiative (Global) Security Working
Group (GSWG)

and Security Architecture Committee (GSAC)

November 1, 2006

#### 

![](media/image3.png){width="5.991666666666666in"
height="0.7777777777777778in"}

#### Table of Contents

[Overview of the Global Federated Identity and Privilege Management
(GFIPM) Essential Components
3](#overview-of-the-global-federated-identity-and-privilege-management-gfipm-essential-components)

[The Global FIPM Metadata (GFIPM-M) and the GFIPM Assertion (GFIPM-A):
Development and Testing
3](#the-global-fipm-metadata-gfipm-m-and-the-gfipm-assertion-gfipm-a-development-and-testing)

[**Metadata for User Assertions** 3](#metadata-for-user-assertions)

[**Metadata Modeling: Leveraging Global JXDM**
3](#metadata-modeling-leveraging-global-jxdm)

[**Uses for Metadata** 4](#uses-for-metadata)

[**GFIPM-M and GFIPM-A Design Process**
5](#gfipm-m-and-gfipm-a-design-process)

[**GFIPM-M /GFIPM---A Process and Timeline**
6](#gfipm-mgfipma-process-and-timeline)

[The DOJ/DHS GFIPM Demonstration Project
7](#the-dojdhs-gfipm-demonstration-project)

[**Demonstration Overview** 8](#demonstration-overview)

[**Federation Participation Premise** 8](#__RefHeading___Toc148840390)

[**User-to-Computer Application Connectivity Use Case**
8](#__RefHeading___Toc148840391)

[**Project Scope** 9](#__RefHeading___Toc148840392)

[**Demonstration Purpose/Objectives** 9](#__RefHeading___Toc148840393)

[**Other Objectives Include:** 10](#__RefHeading___Toc148840394)

[**GFIPM Demonstration Stages:** 10](#__RefHeading___Toc148840395)

[**Stage 1 Overview** 11](#stage-1-overview)

[**Stage 2 Overview** 11](#stage-2-overview)

[**GFIPM: Stage 2 Progress** 14](#gfipm-stage-2-progress)

[**Demonstration Project Timeline** 16](#__RefHeading___Toc148840399)

[**Identity Provider and Service Provider: Development and Testing**
17](#identity-provider-and-service-provider-development-and-testing)

[**Pairwise Testing---Participant Results**
19](#pairwise-testingparticipant-results)

[Demonstration Participant Reports and Lessons Learned
19](#demonstration-participant-reports-and-lessons-learned)

[**JNET** 19](#__RefHeading___Toc148840403)

[**Number of Participating Users** 19](#number-of-participating-users)

[**Participating Users** 19](#participating-users)

[**Resource Information** 20](#resource-information)

[**Participant Statements on GFIPM Concept and Demonstration**
20](#participant-statements-on-gfipm-concept-and-demonstration)

[**RISSNET** 23](#__RefHeading___Toc148840408)

[**Number of Participating Users** 23](#number-of-participating-users-1)

[**Participating Users** 23](#participating-users-1)

[**Resource Information** 23](#resource-information-1)

[**Participant Statements on GFIPM Concept and Demonstration**
23](#participant-statements-on-gfipm-concept-and-demonstration-1)

[**CISAnet** 25](#__RefHeading___Toc148840413)

[**Number of Participating Users** 25](#number-of-participating-users-2)

[**Participating Users** 25](#participating-users-2)

[**Resource Information** 25](#resource-information-2)

[Participant Statements on GFIPM Concept and Demonstration
25](#participant-statements-on-gfipm-concept-and-demonstration-2)

#### Overview of the Global Federated Identity and Privilege Management (GFIPM) Essential Components

At the highest level of concept within the GFIPM model, there are three
vital components that must interact between users of multiple systems:

+---------------------------------------------+------------------------+
| #### Components                             | #### Development Track |
+---------------------------------------------+------------------------+
| #### Identity Provider (IDP)                | #### DOJ/DHS Demo      |
+---------------------------------------------+------------------------+
| #### Service Provider (SP)                  | #### DOJ/DHS Demo      |
+---------------------------------------------+------------------------+
| #                                           | #### GSAC/GSWG         |
| ### User Profile Assertion (GFIPM Metadata) |                        |
+---------------------------------------------+------------------------+

These three major components each represented issues and challenges for
configuring and designing the specific requirements for operating and
testing the GFIPM concept, or paradigm, within the justice information
sharing community.

Although much of the essential work and development of these components
was initiated by the Global Security Working Group (GSWG) and performed
by the Global Security Architecture Committee (GSAC) with the technical
assistance and services of Georgia Tech Research Institute (GTRI),
further development, implementation, and testing was conducted within
the U.S. Department of Justice (DOJ)/U.S. Department of Homeland
Security (DHS) GFIPM Demonstration Project*.*

#### The Global FIPM Metadata (GFIPM-M) and the GFIPM Assertion (GFIPM-A): Development and Testing

## Metadata for User Assertions

The concept of the common or globally understood metadata across
federation systems is the linchpin to GFIPM interoperability. Just as a
common Extensible Markup Language (XML) data model was the key to data
interoperability, a standard set of XML elements and attributes about a
federation user's identities, privileges, and authentication details can
be communicated universally. This common metadata, in the form of an
***assertion*** between systems, allows the data owners (service
provider) to process and enforce their local policies and technologies
for providing security, thereby making independent access and data
privacy enforcement decisions about other federation users' requests for
access to specific data or data system resources.

## Metadata Modeling: Leveraging Global JXDM

It is only logical, given the work and success of the Global Justice
Information Sharing Initiative (Global) Justice XML Data Model (Global
JXDM) and National Information Exchange Model (NIEM) data modeling
efforts, to leverage and reuse these specifications in describing the
GFIPM assertions. The further advantage of the NIEM specification is
that it inherently makes the model immediately more applicable to other
domains and systems, rather than focused on criminal justice users and
systems. The design requirements for the GFIPM assertion include 1)
identifying the attributes needed to support the use cases for
interoperable federated identity and privilege management;\
2) identifying the standard technology and representation for these
attributes; and\
3) defining the "assertions" structure for the technology employed.

## Uses for Metadata

There have been four major purposes, or use cases, supported by the
design decisions of the GFIPM Metadata and Assertion process:

-   Identification/Authentication---*Those attributes needed to
    communicate identification of end users and the associated
    authentication context. Who is the end user, and how did they
    authenticate?*

-   Privilege Management---*Those attributes captured by identity
    providers (IDPs) which can assist service providers (SPs) in making
    authorization decisions. What certifications, clearances, job
    functions, local privileges, and organizational affiliations are
    associated with the end user that can serve as the basis for
    authorization decisions?*

-   Audit---*Those attributes needed or required for the purposes of
    auditing systems, system access, use, and legal compliance of data
    practices.*

-   Personalization---*Those attributes that can enable local systems to
    feature specialized services, regionalization, or special interest
    characteristics of their local software (e.g., regional news or
    alerts, special interest group (SIG) information, display, and tool
    settings or preferences).*

# GFIPM-M and GFIPM-A Design Process

The development process for the GFIPM assertion has been based on a
limited scope. The primary focus has been on the collection of
attributes (metadata) required to support the GFIPM use cases and
specify federated users and federated entities in accordance with known
and applicable industry standards. The scope was initially limited to
responses provided by GSAC survey participants.

The first level of development was the identification and collection of
metadata,\
GFIPM-M, based on the survey results of GSAC members and the systems
that they represent. This initial set of metadata was grouped and
harmonized among the independent responses and then mapped to NIEM 0.3
as the base vocabulary. This resulted in a straw man set of metadata,
which was then vetted back with the entire GSAC, a separate GSAC GFIPM
tiger team, and the DOJ/DHS GFIPM demonstration project participants.
This resulted in the GFIPM-M 0.2 package that is being used by the
demonstration project today. Lessons learned from this project to date
have been captured and incorporated into the GFIPM-M 0.3 package, which
is the current version and provides the basis for further development
and expanded vetting.

The next level of the development process seeks to build this metadata
set into the form of a technology standardized assertion format, which
will result in the Global Federated Identity and Privilege Management
Assertion (GFIPM-A). Several different techniques for encoding this
metadata into Security Assertion Markup Language (SAML) assertions have
been identified and documented as part of the GFIPM-M 0.3 package.
Lessons learned from the demonstration project and feedback from the
broader community will lead to a specific recommendation and standard
for the GFIPM-A.

The distinction of the attributes available within GFIPM-M is specific
to the requirements for describing either a user or a federation entity.
In other words, the GFIPM-M supports both the necessary attributes for
system-to-system, system-to-user, and/or user-to-user contexts for
information sharing. The profile or use cases of creating either a
federation entity assertion or a user assertion are subsetted within the
GFIPM-M. Separately, the GFIPM-A specification will detail the
attributes and requirements for SAML encoding, binding, and assertion
transport for either assertion use case. However, beyond the context of
GFIPM-M, it should be noted that a comprehensive collection of all
security metadata requirements required for the justice or national
information sharing community, including privacy, Service-Oriented
Architecture (SOA), networking, other layers of the security stack, and
a comprehensive security process were considered outside the scope of
this initial survey and draft specifications.

## GFIPM-M/GFIPM---A Process and Timeline

+--------------+--------------------------------------------+-----------+
| **Process**  | **Description**                            | **Sta     |
|              |                                            | tus/Due** |
+--------------+--------------------------------------------+-----------+
| ***Call for  | An initial set of data requirements was    | *         |
| Data         | solicited from the Global Security         | **Done*** |
| Req          | Architecture Committee participants via a  |           |
| uirements*** | simple set of questions. Many of the GSAC  | ***Aug    |
|              | participants represent systems and         | 2005***   |
|              | networks with embedded identity and        |           |
|              | privilege management requirements in       |           |
|              | operation today.                           |           |
+--------------+--------------------------------------------+-----------+
| ***Collect   | Place submissions in a consistent          | *         |
| and Compile  | machine-readable format for manipulation   | **Done*** |
| Survey       | and analysis.                              |           |
| Results***   |                                            | ***Sept   |
|              |                                            | 2005***   |
+--------------+--------------------------------------------+-----------+
| ***Validate  | -   Ensure that all submitted data         | *         |
| Data         |     requirements are associated with       | **Done*** |
| Requirement  |     unambiguous, semantically precise      |           |
| Submissions  |     definitions.                           | ***Oct    |
| for          |                                            | 2005***   |
| Completeness | -   Determine representation and content   |           |
| and          |     for each data requirement (e.g.,       |           |
| Clarity***   |     numeric, text, code). NIEM core        |           |
|              |     representation types provided the      |           |
|              |     basis for typing data components.      |           |
+--------------+--------------------------------------------+-----------+
| *            | The following standards will be considered | *         |
| **Supplement | for the extraction of data requirements:   | **Done*** |
| With         |                                            |           |
| Attributes   | -   Security Assertion Markup Language     | ***Oct    |
| From         |     (SAML) 2.0 series of specifications.   | 2005***   |
| Applicable   |                                            |           |
| Standards as | -   Liberty Alliance ID-SIS 1.0 series of  |           |
| Required***  |     specifications.                        |           |
|              |                                            |           |
|              | -   Liberty Alliance ID-FF 2.0 series of   |           |
|              |     specifications.                        |           |
|              |                                            |           |
|              | -   Internet Engineering Task Force        |           |
|              |     (IETF) - inetOrgPerson (RFC 2798)      |           |
|              |     derived from X.521 person and          |           |
|              |     organizationalPerson with additional   |           |
|              |     attributes.                            |           |
+--------------+--------------------------------------------+-----------+
| ***Logically | Analysis of the submitted data             | *         |
| Group        | requirements will ultimately determine the | **Done*** |
| Attributes   | categorization and aggregation of          |           |
| Into         | attributes.                                | ***Nov    |
| C            |                                            | 2005***   |
| ategories*** |                                            |           |
+--------------+--------------------------------------------+-----------+
| ***Develop   | A straw man was developed from the         | *         |
| Straw Man*** | superset of candidate attributes from      | **Done*** |
|              | survey submissions and applicable          |           |
|              | standards for each of the categories       | ***Dec    |
|              | defined above.                             | 2005***   |
+--------------+--------------------------------------------+-----------+
| ***Vet and   | -   The initial vetting of the straw man   | *         |
| Refine Straw |     was through the Global Security        | **Done*** |
| Man***       |     Architecture Committee members. Survey |           |
|              |     participants validated mappings        | ***Jan    |
|              |     between their submissions and the      | 2006***   |
|              |     resultant straw man for semantic       |           |
|              |     consistency.                           |           |
|              |                                            |           |
|              | -   Feedback was solicited and             |           |
|              |     incorporated. The straw man was        |           |
|              |     updated and provided as a              |           |
|              |     recommendation by GSAC for review and  |           |
|              |     vetting to a broader Global community. |           |
+--------------+--------------------------------------------+-----------+
| ***Harmonize | -   Once consensus has been reached on the | ***O      |
| With         |     data requirements, semantics, and      | ngoing*** |
| Current\     |     representation of the GFIPM Security   |           |
| Version of   |     Assertion, it will be semantically and | *         |
| G            |     structurally harmonized with the       | **Through |
| JXDM/NIEM*** |     current version of the Global JXDM.    | April     |
|              |     Attributes that are currently in the   | 2007      |
|              |     Global JXDM will be mapped, while new  | (NIEM     |
|              |     data requirements will be submitted    | 1.1)***   |
|              |     for inclusion in a future version of   |           |
|              |     the Global JXDM. This will be an       | ***In     |
|              |     ongoing activity until the convergence | itial:*** |
|              |     and stabilization of NIEM and Global   |           |
|              |     JXDM.                                  | ***Feb    |
|              |                                            | 2006***   |
|              | -   Data requirements and associated       |           |
|              |     attributes derived from existing       |           |
|              |     standards (SAML) will be referenced in |           |
|              |     the GFIPM Assertion for completeness   |           |
|              |     but not duplicated in the Global JXDM. |           |
+--------------+--------------------------------------------+-----------+

+--------------+--------------------------------------------+-----------+
| **Process**  | **Description**                            | **Sta     |
|              |                                            | tus/Due** |
+--------------+--------------------------------------------+-----------+
| ***Advanced  | -   A GSAC representative Tiger Team was   | ***O      |
| Vetting of   |     established for continued vetting and  | ngoing*** |
| the GFIPM    |     design process of the GFIPM metadata   |           |
| Metadata***  |     and assertion specification            | *         |
|              |     development. An initial vetting        | **Through |
|              |     session was conducted in March 2006.   | 2006***   |
|              |                                            |           |
|              | -   Broader vetting of the GFIPM-M is      | **        |
|              |     required prior to making a full        | *Initial: |
|              |     recommendation for implementation. The | March     |
|              |     GSWG and Global community will         | 2006***   |
|              |     continue to serve as the vehicle for   |           |
|              |     this expanded vetting of GFIPM-M.      |           |
+--------------+--------------------------------------------+-----------+
| **           | -   GFIPM-M was published in a separate    | ***O      |
| *Incorporate |     document along with a NIEM             | ngoing*** |
| Feedback and |     representation. This corresponded to   |           |
| Iteratively  |     the GFIPM-M 0.2 distribution package.  | *         |
| Refine and   |                                            | **Through |
| Publish      | -   Based on feedback from the vetting     | 2006***   |
| "Draft"      |     process and lessons learned from the   |           |
| GFIPM        |     DHS/DOJ demonstration process,         | ***In     |
| Metadata     |     additional versions of the GFIPM-M     | itial:*** |
| Packages***  |     package will be published. The current |           |
|              |     version of GFIPM-M is the 0.3 version. | ***April  |
|              |                                            | 2006***   |
+--------------+--------------------------------------------+-----------+
| ***Develop   | -   A set of alternatives for encoding     | ***O      |
| and Vet      |     GFIPM-M in SAML along with pros and    | ngoing*** |
| GFIPM-A      |     cons have been identified and          |           |
| Spec         |     documented. This is included as a      | *         |
| ification*** |     separate document as part of the       | **Through |
|              |     GFIPM-M 0.3 package.                   | April     |
|              |                                            | 2007***   |
|              | -   The demonstration project participants |           |
|              |     have reviewed and deliberated on these | ***In     |
|              |     alternatives and selected one of these | itial:*** |
|              |     alternatives for use in the            |           |
|              |     demonstration project. Lessons learned | ***       |
|              |     will be captured from the              | September |
|              |     demonstration project leading to       | 2006***   |
|              |     further specification and              |           |
|              |     recommendations for the GFIPM-A.       |           |
|              |                                            |           |
|              | -   Additionally, specific encoding        |           |
|              |     techniques have implications with      |           |
|              |     regard to commercial off-the-shelf     |           |
|              |     (COTS) product support. Some limited   |           |
|              |     COTS testing is being conducted as     |           |
|              |     part of the demonstration product.     |           |
|              |     Lessons learned will be captured and   |           |
|              |     provided to GSAC/GSWG for              |           |
|              |     consideration.                         |           |
+--------------+--------------------------------------------+-----------+

#### The DOJ/DHS GFIPM Demonstration Project

The concept of a federation has emerged from the Global Security
Architecture Committee and has received growing interest from several
local, state, regional, and federal systems. As a result, a
demonstration project was initiated under the cosponsorship of the U.S.
Department of Justice (DOJ) and the U.S. Department of Homeland Security
(DHS). The initial phase of this proof of concept included participation
from the Criminal Information Sharing Alliance network (CISAnet),
Pennsylvania Justice network (JNET), and the Regional Information
Sharing Systems^®^ (RISS) network (RISSNET™). Others expressing interest
in participating in the demonstration during follow-on phases include
the California Department of Justice, Wisconsin Department of Justice,
DHS's Homeland Security Information Network (HSIN)/Joint Regional
Information Exchange System (JRIES), and the Automated Regional Justice
Information System (ARJIS). The data requirements and the resultant set
of vetted attributes identified through this survey process will be
validated operationally as part of the GFIPM demonstration project.

## Demonstration Overview

Use of standard agreements, industry standards, and open
standards-compliant technologies make identity and entitlements portable
across autonomous domains, organization to organization, organization to
individual, or individual to individual. Once an identity provider has
authenticated a user, that individual can be recognized easily and take
part in the services offered by other federation service providers.
Based on trust and standards, federated versus centralized identity
management offers a scalable alternative to address the interdomain
security challenge.

**Federation Participation Premise**[]{#__RefHeading___Toc148840390
.anchor}

-   Federation participants retain control over their resources,
    applications, and databases. Dissemination and access control
    decisions are made locally.

-   Each federation participant registers with a certified identity
    provider and administers their subscriber base.

-   Federation participants can implement local technologies and
    mechanisms.

-   All federation participants agree to a minimal set of policies,
    procedures, and standards, allowing for subscriber authentication
    and privilege information to be passed between participants in a
    manner that is trusted and well-known.

-   Federation participation in the federation does not preclude
    independent out-of-band bilateral agreements between participants.

Three distinct use-case scenarios have been identified by the Global
Security Architecture Committee as applicable to information sharing
between local, state, regional, tribal, and federal agencies: 1)
system-to-system connectivity, 2) user-to-application connectivity, and
3) user-to-user/system-to-user messaging. Although each use-case
scenario is pertinent and must eventually be addressed, the
user-to-application connectivity use-case scenario was the focus of the
demonstration project to keep the scope of the project manageable.

**User-to-Computer Application Connectivity Use
Case**[]{#__RefHeading___Toc148840391 .anchor}

Essentially, *User A* of *System A* needs to connect to the application
resources offered by *System B,* begging the question, ***How do
applications made accessible by System B identify, authenticate,
authorize, entitle, and ultimately trust users of System A?*** Although
the answer will differ based on the particular system and application,
the initial demonstration use-case scenario will be to facilitate
secure, authenticated access to static Web content that requires the
identification and authentication of a ***group,*** ***role,*** or
***sponsoring*** ***system*** to which a given user belongs.
Characteristics of the user-to-application identity and authentication
use case include the following:

-   A valid subscriber of System A can access a Web-based application of
    System B, a federation participant.

-   A valid subscriber of System B can access a Web-based application of
    System A, a federation participant.

-   A subscriber registers locally and is not required to reregister to
    another federation participant's system or application. Registration
    is completed when an individual user is vetted and assigned an
    electronic credential.

-   A subscriber authenticates locally and is not required to
    reauthenticate to another federation application, even if the
    subscriber has traversed multiple applications within the
    federation.

-   Subscriber information in the form of an agreed-upon set of
    attributes is passed to the system or application such that access
    control decisions can be made without local provisioning.
    Provisioning is the act of setting up a user account that allows a
    registered user access to local system resources.

    **Project Scope**[]{#__RefHeading___Toc148840392 .anchor}

The scope of the demonstration project was to develop and prove an
identity and privilege management service that can be used to apply
authentication and access controls by disparate systems and networks
desiring to make their resources sharable. The outcome was intended to
demonstrate a universal mechanism, implementation-independent, and
nonvendor-specific, designed to share trusted assertions in the form of
an agreed set of attributes that can be used to apply authentication and
access controls.

The demonstration was limited to:

-   The user-to-computer application use case.

-   Web-based applications only.

-   JNET, CISAnet, and RISSNET to prove the concept.

-   Open-source, noncommercial software to keep the software licensing
    costs to a minimum.

    **Demonstration Purpose/Objectives**[]{#__RefHeading___Toc148840393
    .anchor}

The focus of the demonstration project was to 1) achieve a quick win, 2)
capture lessons learned, and 3) lay a foundation of experience on which
participants, stakeholders, and sponsors can assess the value and
feasibility of a security and information sharing architecture based on
federated identity and privilege management. The intent was to
demonstrate a real-life multidirectional, electronic exchange of
criminal intelligence information, achieved through secure
interoperability between networks and information systems currently not
capable of doing so.

**Other Objectives Include:**[]{#__RefHeading___Toc148840394 .anchor}

1.  Demonstrate that registered subscribers of one federation
    participant can access the Web-based resources of another federation
    participant without the requirement to register with more than one
    federation participant.

```{=html}
<!-- -->
```
1.  Demonstrate that federation participants can retain control over
    their resources, applications, and databases and make local
    dissemination and access control decisions based on a shared set of
    standard subscriber attributes.

2.  Demonstrate single sign-on across federation Web applications.

3.  Demonstrate federated authentication and authorization between
    disparate local technologies and vendor implementation.

4.  Establish a baseline of common attributes for identity and
    authorization assertions.

5.  Provide an open-source free version of the GFIPM infrastructure
    available to the community and vendors for the implementation of
    Identify Providers and Service Providers.

**GFIPM Demonstration Stages**[]{#__RefHeading___Toc148840395 .anchor}

The GFIPM federation deployment schedule contains four distinct
deployment stages. Each of these stages is listed and described below.

  ----------- --------------------------------------------------------------
  **Stage**   **Goals**

  **1**       Basic Infrastructure Deployment With the Shibboleth 1.3\
              Open Source Implementation of SAML 1.1

  **2**       Implementation of Live Systems Within the Infrastructure

  **3**       Migration to Shibboleth 2.0 / SAML 2.0

  **4**       Interoperability Testing With COTS SAML 2.0 Products
  ----------- --------------------------------------------------------------

*NOTE: Stages 1 and 2 described here correspond to Phase II and Phase
III of the project as described below. Stage 3 and 4 above were
originally outside the scope of the demonstration project but have been
included based on the desires of the project participants and will be
addressed as part of the demonstration project as time and funding
permit.*

## Stage 1 Overview

During Stage 1, each participant will set up the basic Shibboleth
infrastructure on local hardware. There are two Shibboleth components
that each participant must set up: an Identity Provider (IDP) and a
Service Provider (SP). At the end of Stage 1, the federation will be
operational in the sense that each participant\'s IDP will be able to
interface properly with each SP in the federation, and each
participant\'s SP will be able to interface properly with each IDP in
the federation. Each participant must choose an operating system
platform for the IDP and SP during Stage 1. The choices are Microsoft
Windows 2003 and Red Hat Enterprise Linux (RHEL). Links to
platform-specific instructions for setting up an IDP and an SP on each
platform are located below, as well as at the navigation pane on the
left side of the page.

## Stage 2 Overview

During Stage 2, each participant will transform their basic Shibboleth
infrastructure components from Stage 1 demo components into live,
working Identity Provider and Service Provider systems that provide
federated access to live information resources for actual users. There
are three basic tasks that participants must complete during Stage 2:

> 1\. **[Live SSO System Integration]{.underline}**---Replace the Stage
> 1 demo user name and password Single Sign-On (SSO) authentication
> system with a production-quality SSO system that can authenticate
> actual users.

![](media/image4.jpeg){width="4.145833333333333in"
height="3.1041666666666665in"}

## 2. [Live Attribute Repository Integration]{.underline}---Replace the Stage 1 demo attribute connectors with software that connects to a live attribute repository, and a Limited Directory Access Protocol (LDAP) repository queries the repository for the appropriate attributes and transforms the results into a format that is compliant with the GFIPM User Assertion 0.2. 

![](media/image5.jpeg){width="4.145833333333333in"
height="3.1041666666666665in"}

> ![](media/image6.jpeg){width="4.145833333333333in"
> height="3.1041666666666665in"}3. **[Live-Protected Resource
> Integration]{.underline}**---Replace the Stage 1 demo-protected
> resource with a live application or resource that provides useful
> information to federated users and incorporates appropriate access
> control logic based on information received from identity providers
> via GFIPM User Assertion Demo Profile Instances.

In support of these tasks, GTRI has created the following tools and
documentation items.

1.  **GFIPM Assertion 0.2 Package**

> This package contains the formal specification for the GFIPM User
> Assertion, Version 0.2, and the GFIPM Entity Assertion, Version 0.2.
> It specifies the assertions at two logical levels: the reference model
> level, which is optional and over-inclusive, and the demonstration
> profile level. The reference model, sometimes called the conceptual
> model, is specified via a Microsoft Word document and a Microsoft
> Excel spreadsheet. The demonstration profile is specified by a
> Microsoft Excel spreadsheet and an XML schema.

2.  **Instructions for Configuring Tomcat X.509 Client Certificate
    Authentication**

> These instructions describe how to configure the Tomcat Web servlet
> container to perform client certificate authentication using X.509
> client certificates.

3.  **Stage 2 Configuration Instructions for a Shibboleth Service
    Provider**

> These instructions describe how to configure a Shibboleth Service
> Provider (SP) to consume a GFIPM User Assertion Demo Profile Instance.

4.  **Attribute File Streamer Connector**

> The Attribute File Streamer Connector is a custom attribute repository
> connector for a Shibboleth Identity Provider (IDP). When used in an
> IDP, it can cause the IDP to transmit the contents of a specified text
> file on the local file system as the value for a specified SAML
> attribute within a SAML attribute assertion. Available are a zip file
> with the Attribute File Streamer Connector code, a sample GFIPM User
> Assertion Demo Profile Instance, and instructions for deployment and
> use.

5.  **GFIPM User Assertion LDAP Connector**

> The GFIPM User Assertion LDAP Connector is a custom attribute
> repository connector for a Shibboleth Identity Provider (IDP). When
> used in an IDP, it can connect to an LDAP data repository, query the
> LDAP repository for necessary attributes, transform the LDAP
> attributes into a form that constitutes a GFIPM User Assertion Demo
> Profile Instance, and hand the result off to Shibboleth for
> transmission as an SAML attribute value within an SAML attribute
> assertion.

6.  **Stage 2 Reference Identity Provider**

> This [Identity Provider
> (IDP)](http://gfipm.gtri.gatech.edu/participants/shib/testing_sp_with_reference_idp.html)
> can interoperate with a Service Provider (SP) and generate several
> different profile instances, so that developers can verify the SP\'s
> ability to receive each instance and restrict access according to an
> appropriate policy.

Finally, to help GFIPM participants test their Stage 2 systems, the GTRI
is developing a reference service provider.

[**Stage 2 Reference Service
Provider**](http://gfipm.gtri.gatech.edu/participants/shib/reference_sp.html)---This
is a Service Provider (SP) that can interoperate with an Identity
Provider (IDP) and perform several types of validation for the profile
instances that the IDP sends to it. The first type of validation is to
verify that the profile instance is compliant with the demo profile
schema. The second type of validation is to verify that the profile
instance contains all of the elements that have been marked as mandatory
for the demo profile. The third type of validation is to analyze the
data in the profile instance and generate a report describing which
protected resources would be available at each participant\'s SP for a
user with this profile instance.

## GFIPM: Stage 2 Progress

Stage 2 of the GFIPM deployment cycle involved each participant
integrating Shibboleth with their existing services. For Identity
Providers, this meant integrating Shibboleth with their existing
log-in/single sign-on system, as well as integrating their LDAP
attribute repositories with Shibboleth via the GFIPM Custom Data
Connector. For Service Providers, this meant consuming a GFIPM User
Assertion and performing access control based on its contents for a
given service (or set of services).

During Stage 1, it was easy to declare the systems that are working by
third-party inspection, but the current IDPs are only accessible to
personnel from each organization, so each organization must verify
independently that their IDPs are working. Additionally, each
organization is unable to verify that their SPs work with each IDP in
turn, as they can test only against their own IDP and, in some cases,
the Reference IDP. In many cases, the Reference IDP will be correctly
denied access to sensitive services, making it an ineffectual test tool.

### CISA

+-----------+----------------------------------------------------------+
| **Authent | CISA is using Client Certificate Authentication based on |
| ication** | certificates issued to CISAnet members for use with      |
| In        | their current network. This authentication is            |
| tegration | functional.                                              |
| Point     |                                                          |
+-----------+----------------------------------------------------------+
| **        | CISA is using an LDAP repository filled with user        |
| Attribute | attributes. It is using the [GFIPM User Assertion LDAP   |
| Repo      | Connector v                                              |
| sitory**\ | 1.0.1](http://gfipm.gtri.ga                              |
| In        | tech.edu/participants/shib/gfipm_assertion_builder.html) |
| tegration | to generate GFIPM User Assertions based on the contents  |
| Point     | of their LDAP database. The generated user assertions    |
|           | have been tested with the [GFIPM Stage 2 Reference       |
|           | Service                                                  |
|           | Provider](https://linu                                   |
|           | xrefsp.gfipm.gtri.gatech.edu/secure/GFIPMMandatory.php). |
+-----------+----------------------------------------------------------+
| *         | CISA is currently planning on making all services        |
| *Services | specified on their [participant                          |
| P         | overview](http:/                                         |
| rovided** | /gfipm.gtri.gatech.edu/participants/overviews/CISA.html) |
|           | available.                                               |
|           |                                                          |
|           | 1.  Arizona Counter-Terrorism Information                |
|           |     Center---Unavailable                                 |
|           |                                                          |
|           | 2.  Arizona Sex Offender Information                     |
|           |     Center---Unavailable                                 |
|           |                                                          |
|           | 3.  Arizona Department of Public Safety                  |
|           |     GANGNET---Unavailable                                |
|           |                                                          |
|           | 4.  CISAnet Federated Query Tool (CFQT)---Unavailable    |
|           |                                                          |
|           | 5.  Georgia Bureau of Investigation Sex Offender         |
|           |     Registry---Unavailable                               |
|           |                                                          |
|           | 6.  Oklahoma State Bureau of Investigation Officer       |
|           |     Safety Bulletin---Unavailable                        |
|           |                                                          |
|           | 7.  Texas Criminal Law Enforcement Online                |
|           |     (CLEO)---Unavailable                                 |
+-----------+----------------------------------------------------------+

### JNET

+-----------+-----------------------------------------------------------+
| *         | JNET is using Client Certificate Authentication based on  |
| *Authenti | certificates issued to JNET members. This authentication  |
| cation**\ | is functional.                                            |
| In        |                                                           |
| tegration |                                                           |
| Point     |                                                           |
+-----------+-----------------------------------------------------------+
| **        | JNET is using an LDAP repository filled with user         |
| Attribute | attributes. It is using the [GFIPM User Assertion LDAP    |
| Repo      | Connector v                                               |
| sitory**\ | 1.0.1](http://gfipm.gtri.g                                |
| In        | atech.edu/participants/shib/gfipm_assertion_builder.html) |
| tegration | to generate GFIPM User Assertions based on the contents   |
| Point     | of their LDAP database.                                   |
+-----------+-----------------------------------------------------------+
| *         | JNET is currently planning on making some subset of the   |
| *Services | services specified in their [participant                  |
| P         | overview](http:                                           |
| rovided** | //gfipm.gtri.gatech.edu/participants/overviews/JNET.html) |
|           | available. Many of these services are pending the         |
|           | permission of the organization that owns the resource.    |
|           |                                                           |
|           | 1.  Pennsylvania Driver\'s License Photos---Pending       |
|           |     Organizational Permission                             |
|           |                                                           |
|           | 2.  Pennsylvania Department of Corrections Intake/Exit    |
|           |     Photos---Pending Organizational Permission            |
|           |                                                           |
|           | 3.  Pennsylvania Probation \"Fail to Report\" Photos and  |
|           |     Cases---Available---JNET reports this as operational  |
|           |     for JNET and soon for RISS/CISA.\                     |
|           |     *Requires*: Government Data Search Privileges.        |
|           |                                                           |
|           | 4.  Pennsylvania State Prisoner Locator---Pending         |
|           |     Organizational Permission                             |
|           |                                                           |
|           | 5.  Pennsylvania Criminal Trial Case                      |
|           |     Information---Pending Organizational Permission       |
|           |                                                           |
|           | 6.  Pennsylvania Arrest Warrants Outstanding for Failure  |
|           |     to Pay Child Support---Pending Organizational         |
|           |     Permission                                            |
|           |                                                           |
|           | 7.  White Pages of Pennsylvania Justice Staff---Pending   |
|           |     Organizational Permission                             |
|           |                                                           |
|           | 8.  Pennsylvania Amber Alert---Pending Organizational     |
|           |     Permission                                            |
+-----------+-----------------------------------------------------------+

### RISS

+-----------+----------------------------------------------------------+
| *         | RISS is using Client Certificate Authentication on their |
| *Authenti | IDP.                                                     |
| cation**\ |                                                          |
| In        |                                                          |
| tegration |                                                          |
| Point     |                                                          |
+-----------+----------------------------------------------------------+
| **        | RISS is using an Active Directory repository filled with |
| Attribute | user attributes. It is using the [GFIPM User Assertion   |
| Repo      | LDAP Connector v                                         |
| sitory**\ | 1.0.1](http://gfipm.gtri.ga                              |
| In        | tech.edu/participants/shib/gfipm_assertion_builder.html) |
| tegration | to generate GFIPM User Assertions based on the contents  |
| Point     | of their Active Directory (Active Directory supports the |
|           | LDAP protocol).\                                         |
|           | \                                                        |
|           | RISS will consider updating with what attributes they    |
|           | populate a GFIPM User Assertion as time moves forward.   |
|           | For the moment, it is complete.                          |
+-----------+----------------------------------------------------------+
| *         | RISS is currently planning on making all services        |
| *Services | specified on their [participant                          |
| P         | overview](http:/                                         |
| rovided** | /gfipm.gtri.gatech.edu/participants/overviews/RISS.html) |
|           | available:                                               |
|           |                                                          |
|           | 1.  HSIN Counterterrorism Briefs, Reports, and           |
|           |     Documents---Available\                               |
|           |     *Requires*: Federation Log-In.                       |
|           |                                                          |
|           | 2.  RISS Counterterrorism Briefs, Reports, and           |
|           |     Documents---Available\                               |
|           |     *Requires*: Sworn Law Enforcement Officer and 28 CFR |
|           |     Part 23 Training.                                    |
+-----------+----------------------------------------------------------+

**Demonstration Project Timeline**[]{#__RefHeading___Toc148840399
.anchor}

+-----------+-----------------------------------------------------------+
| **Phase   | **Project Initiation** *(15 Oct--15 Dec)*                 |
| I**       |                                                           |
+-----------+-----------------------------------------------------------+
|           | -   Develop demonstration scenario                        |
|           |                                                           |
|           | -   Technical requirement establishment                   |
|           |                                                           |
|           | -   Develop GFIPM attribute data dictionary               |
+-----------+-----------------------------------------------------------+
| **Phase   | **GFIPM Infrastructure Establishment** *(1 Jan--30 Apr) * |
| II**      |                                                           |
+-----------+-----------------------------------------------------------+
|           | -   Middleware implementation                             |
|           |                                                           |
|           | -   Test-bed establishment                                |
|           |                                                           |
|           | -   Develop IDP/SP Interface Specification/Integration    |
|           |     Guide                                                 |
+-----------+-----------------------------------------------------------+
| **Phase   | **IDP/SP Development and Integration** *(1 May--1 Oct)*   |
| III**     |                                                           |
+-----------+-----------------------------------------------------------+
|           | -   CISA IDP and SP interface development                 |
|           |                                                           |
|           | -   JNET IDP and SP interface development                 |
|           |                                                           |
|           | -   RISS IDP and SP interface development                 |
|           |                                                           |
|           | -   Provide technical assistance to IDP/SP interface      |
|           |     developers                                            |
|           |                                                           |
|           | -   Integration and testing                               |
+-----------+-----------------------------------------------------------+
| **Phase   | **Demonstration, Evaluation, and Assessment** *(1 Nov--5  |
| IV**      | Jan)*                                                     |
+-----------+-----------------------------------------------------------+
|           | -   Conduct demonstrations for stakeholder and funding    |
|           |     agencies                                              |
|           |                                                           |
|           | -   Collect feedback and lessons learned                  |
|           |                                                           |
|           | -   Incorporate refinements as appropriate                |
|           |                                                           |
|           | -   Identify next steps                                   |
|           |                                                           |
|           | -   Develop final report                                  |
+-----------+-----------------------------------------------------------+

#### Identity Provider and Service Provider: Development and Testing

Two essential GFIPM components are the Identity Provider mechanism and
the Service Provider mechanism. These are specifically configured
servers dedicated to the functions of interacting with other federation
requests for Identity and Authentication details (IDP) and for
authorizing services and resources (SP).

The GFIPM approach to privilege management is based on a set of
well-defined attributes (metadata) associated with an authenticated
subject (person or application process) that is passed between Identity
Providers (IDPs) and Service Providers (SPs) using trusted security
(SAML) assertions. Service Providers provide business logic, which can
implement their access control policy down to the user level, based on a
trusted set of attributes provided with the request for information or
service. There is no requirement for access control policies or the set
of attributes required to be consistent across the entire federation.
SPs ultimately have the final access control decision and may regulate
access based on the IDP or set of attributes provided. However, some
minimal supported set of standard attributes and general guidelines for
what is expected for access to different types of information should be
provided.

IDPs are responsible for authenticating their subscribers and
constructing security (SAML) attribute assertions based on information
that they either collect and maintain directly or that they have access
to via a trusted relationship with one or more attribute authorities. In
providing the essential constructs of these components, the GFIPM
Project sought to develop and test a prototype of both the IDP and the
SP mechanisms and further sought to develop these in open-source
software as reference implementations that could be reused and
reconfigured by the Global justice practitioner community.

For the process of development and testing these concepts, a set of
objectives and implementation parameters were considered, including, but
not limited to, the following:

-   Demonstrate a working single sign-on function in a GFIPM system.

-   Demonstrate a working single sign-off, also known as a global
    log-out function, in a GFIPM system.

-   Demonstrate the ability of a GFIPM Service Provider to enforce
    access control policies on federated users.

-   Demonstrate that both the GFIPM IDP and SP models can interoperate
    with all of the demonstration participants (CISAnet, RISSNET, and
    JNET) without modification or, alternatively, implement the
    modifications required to achieve such interoperability.

-   For commercial security products, demonstrate SAML protocol-level
    interoperability between the open-source-based SAML (Shibboleth) and
    an identity provider using test COTS products or, alternatively,
    determine exactly why the product is incompatible.

-   Demonstrate GFIPM components with common operating systems and
    directories: Windows XP, Linux Red Hat, and LDAP.

-   Evaluate and determine which Security Assertion format best fits the
    GFIPM strategy/architecture in terms of performance,
    interoperability, security, and operational efficiency.

-   Identify, document, and develop the necessary tools and scripts for
    installation, configuration, and life-cycle management of the
    federation middleware, SAML, and open-source components.

-   Demonstrate the scalability of a GFIPM-based federation.

-   Provide technical input necessary for the development of policies
    and procedures for adding new member organizations to a GFIPM-based
    federation and removing member organizations from the federation.

-   Provide technical input necessary for the development of policies
    and procedures for the initial deployment and subsequent management
    of a PKI solution to support the cryptographic requirements and
    needs of a GFIPM-based federation.

-   Demonstrate the reusability of all custom software tools developed
    for a GFIPM-based federation as part of this demo.

### Pairwise Testing---Participant Results

  -------------- -------------- ------------------ -------------- ----------------------
  **Service      **Identity     **Authenticate**   **Redirect**   **Attributes and
  Provider**     Provider**                                       Backchannel**

  **GTRI                                                           
  Reference**                                                     

                 RISS           yes                yes            yes

                 CISA           yes                yes            yes

                 JNET           yes                yes            yes

  **RISS**                                                        

                 GTRI Reference yes                yes            yes

                 RISS           yes                yes            yes

                 CISA           yes                yes            yes

                 JNET           yes                yes            yes

  **CISA**                                                        

                 GTRI Reference yes                yes            firewall issues\*

                 RISS           yes                yes            firewall issues\*

                 CISA           yes                yes            yes

                 JNET           yes                yes            firewall issues\*

  **JNET**                                                        

                 GTRI Reference yes                yes            yes

                 RISS           yes                yes            yes

                 CISA           yes                yes            yes

                 JNET           yes                yes            yes
  -------------- -------------- ------------------ -------------- ----------------------

### \* Tested with firewall temporarily disabled and everything worked.

All tests were performed from within a GTRI subnet. This may have
impacted the results of any tests above in which special firewall rules
apply to this network.

### Demonstration Participant Reports and Lessons Learned

**[JNET]{.underline}**[]{#__RefHeading___Toc148840403 .anchor}

#### Number of Participating Users

Approximately 50 users from JNET will have access to GFIPM resources.

#### Participating Users

JNET users of GFIPM resources will consist of the following user types:

-   Adult Probation Supervisors

-   Chiefs of Police

-   District Attorney Office Staff Members

-   Domestic Relations Officers

-   Emergency Management Chiefs

-   Lieutenants/Sergeants/Detectives

-   Police Officers

-   Probation Officers

-   TAC Officers

#### Resource Information

The following JNET resources are available to GFIPM users:

-   Pennsylvania Driver\'s License Photos

-   Pennsylvania Department of Corrections Intake/Exit Photos

-   Pennsylvania Probation "Fail to Report" Photos and Cases

-   Pennsylvania State Prisoner Locator

-   Pennsylvania Criminal Trial Case Information

-   Pennsylvania Arrest Warrants Outstanding for Failure to Pay Child
    Support

-   White Pages of Pennsylvania Justice Staff

-   Pennsylvania Amber Alert

*Note: Availability of the above JNET resources is currently pending
approval by the appropriate data owners and policymakers within the JNET
governance bodies.*

#### Participant Statements on GFIPM Concept and Demonstration

[JNET and the Federated Identity and Privilege Management
Concept]{.underline}

1.  The value of the GFIPM concept to JNET and the JNET community.

    a.  The GFIPM concept of trusting a federation member agency's own
        registration system to provide the most accurate and current
        identity and home privilege information on a user is
        unquestionably the most reasonable approach to take if data
        sharing among agencies is to be done at a national level. No
        amount of due diligence by an external agency can replace the
        diligence of the agencies closest to those requesting the data.
        To date, the experience of the GFIPM pilot demonstrates the
        approach of relaying identity and home privilege information to
        a federation service provider has been shown to be viable,
        reliable, and secure. In addition, this approach has also
        demonstrated its value in the international college and
        university community, which has been using Shibboleth for some
        time.

# The value of this concept to the JNET community is elimination of the redundant registration process for federation member agencies and the elimination of expensive and cumbersome VPNs, remote user gateways, and closed intranets by using the public Internet and FIPS 140-2-compliant security instead. The savings will be a direct-dollar reduction in costs and a reduction in costs associated with time saved by practitioners, given the reduction in the complexity involved in obtaining information from member agencies within the federation. Quickly sharing this type of information will allow our participants to be far more effective. 

b.  Use of the public Internet will also expand the number of mobile
    users because their home agencies will not have to install mobile to
    intranet gateways.

```{=html}
<!-- -->
```
2.  The most promising aspects of GFIPM for information sharing with
    users outside JNET are as follows:

    a.  The ease with which new users can begin accessing JNET resources
        without reregistration or can access role decisionmaking by each
        individual user.

    b.  That JNET service provider agencies will still set the criteria,
        now expressed as the requirements for specific GFIPM User
        Assertions, to protect their content.

3.  Lessons learned during system setup, development, and unit testing.

    a.  Because every federation member must map at least some
        questionable data from legacy identity management systems, JNET
        found it necessary to explain to the end user how JNET
        interpreted their home privileges and how it impacted their JNET
        privileges. The end user is then required to digitally reaffirm
        their identity and confirm that their home privileges are
        correct. The resulting signature act, upon risk of false
        swearing and forgery, is sufficient for JNET member agencies to
        trust the end-users' assertions.

    b.  Existing user enrollment and registration systems in most
        justice environments should be upgraded to full identity and
        privilege management systems, the result being the Identity
        Provider function can create more reliable user assertions for
        the members served.

4.  JNET believes that the GFIPM approach is feasible for achieving
    interoperable security between Global justice information sharing
    partners. The Identity Provider/Service Provider architecture is
    proven and more than adequate to enable information sharing based on
    exchange of User Assertions.

5.  Implementing GFIPM beyond RISS, JNET, and CISAnet.

    a.  The amount of configuration and integration with legacy identity
        systems should not be minimized. Nonetheless, the legacy systems
        are currently protecting the users' home resources and should be
        used for expanding GFIPM rather than waiting for a future
        unspecified, perfect identity-management standard. As the new
        systems and standards are implemented, they can be phased into a
        GFIPM type system with simple style sheet changes without impact
        to end users or established information sharing. End users would
        be unaware of any changes other than those required by their
        home agency.

6.  Continued support of the GFIPM concept.

    a.  JNET encourages the additional work needed to package components
        of GFIPM for easy implementation, preparation of sample
        configuration files, and reworking of the User Assertions based
        on lessons learned during the live GFIPM demonstration pilot.
        JNET also encourages an expanded pilot with additional
        federation members as well as expanded content offerings from
        existing federation members.

> JNET believes the concept is sound and should be supported by Global
> for continued development and implementation.

**RISSNET**[]{#__RefHeading___Toc148840408 .anchor}

#### Number of Participating Users

Approximately five users from RISS will have access to GFIPM resources.

#### Participating Users

RISS users of GFIPM resources will consist of the following user types:

-   Intelligence Analysts

-   Intelligence Technicians

-   Law Enforcement Officers

#### Resource Information

The following RISS resources are available to GFIPM users:

-   Reports, briefs, and documents related to counter-terrorism that are
    provided by the U.S. Department of Homeland Security via the
    Homeland Security Information Network (HSIN).

-   Reports, briefs, and documents related to counter-terrorism that are
    provided by RISS.

#### Participant Statements on GFIPM Concept and Demonstration

[Value of the Federated Identity Model for Expanding Information Sharing
Capabilities]{.underline}

*Note: This document was prepared in response to a request by John
Wandelt, Project Manager of the Global Federated Identity and Privilege
Management (GFIPM) Demonstration Project, and is intended to be used as
input for his presentation to the Global Security Working Group (GSWG)
and the Global Security Architecture Committee (GSAC) at the September
2006 meeting of those groups.*

Federated Identity Management is defined as: "the ***agreements,
standards, and technologies*** that make identity and entitlements
portable across autonomous\
domains."[^1] RISS considers the Federated Identity Management model as
the most appropriate approach to sharing information with its autonomous
partners. The Federated Identity Management model will allow partners in
an information sharing federation to employ a variety of user
identification and access control credentials by encapsulating the vital
content of each type of credential, along with other related
information, into an industry standard Extensible Markup Language (XML)
construct called an assertion.\
The structure of the assertion will conform to the standards established
by the Organization for the Advancement of Structured Information
Standards (OASIS)[^2] as represented in their Security Assertion Markup
Language (SAML) authentication protocol.

The participation of RISS in the Global Federated Identity and Privilege
Management (GFIPM) Demonstration Project is based on its belief in the
Federated Identity Management concept as a foundation for securely
sharing criminal justice and law enforcement sensitive information
across a very broad range of agencies at all levels of government.
RISS's experience in GFIPM to this point in the project has added to
Global's confidence in the Federated Identity Management approach. It
has also provided valuable lessons that will help in future information
sharing endeavors. Of greatest value, perhaps, is the work done on the
metadata that can be used to identify a user who has been authenticated
to their home system in such a way as to allow RISS, acting in its
service provider role, to make a reasonable decision about which of the
RISS resources others are permitted to access. Experience gained working
with federation partners to reach agreement on the complex metadata will
also be of great benefit in future federation endeavors.

**CISAnet**[]{#__RefHeading___Toc148840413 .anchor}

#### Number of Participating Users

#### For the GFIPM Demonstration, CISAnet participants will have ten law enforcement personnel consisting of sworn officers and intelligence analysts per state accessing JNET and RISS available resources, for a total of 100 users.

#### Participating Users

All CISAnet users of GFIPM resources are either sworn officers or
intelligence analysts for one of the following CISAnet participant
agencies:

-   Alabama Bureau of Investigation

-   Arizona Department of Public Safety

-   California Department of Justice

-   Georgia Bureau of Investigation

-   Idaho State Police

-   Louisiana State Police

-   Mississippi Department of Public Safety

-   New Mexico Department of Public Safety

-   Oklahoma State Bureau of Investigation

-   Texas Department of Public Safety

#### Resource Information

The following CISAnet resources are available to GFIPM users:

-   Arizona Counter-Terrorism Information Center (ACTIC)

-   Arizona Sex Offender Information Center

-   Arizona Department of Public Safety GANGNET

-   CISAnet Federated Query Tool (CFQT)

-   Georgia Bureau of Investigation Sex Offender Registry

-   Oklahoma State Bureau of Investigation Officer Safety Bulletin

-   Texas Criminal Law Enforcement Online (CLEO)

#### Participant Statements on GFIPM Concept and Demonstration

As acknowledged during fall of 2005, there are many nationally
recognized sensitive but unclassified (SBU) networks that support
substantial investments in technology and trust relationships that are
not interoperable. A major obstacle to this secure information exchange
and interoperability is that of identity and privilege management. As is
the case with many of these networks, CISAnet users would have to
subscribe to multiple registration processes and manage multiple
security mechanisms and passwords to get access to all the resources
they need. With an increasing demand for secure information sharing
between local, state, and federal agencies, this approach is
unmanageable, frustrating to users, and will not scale to meet the
larger information sharing vision.

The Global Federation Identity and Privilege Management (GFIPM) project
provides a standardized means for allowing agencies to directly provide
services for trusted users that they do not directly manage. The GFIPM
project demonstrates that the identities from three different enterprise
domains, CISAnet, JNET, and RISS, can be granted access to the services
of other enterprises. Although this demonstration project is still in
its early phases, the successes can already be seen.

CISAnet participants agree with the basic GFIPM premise that:

1)  Individual programs can and should vet their own subscriber base.
    CISAnet participating agencies perform this function to the best of
    their ability and have direct responsibility for managing their
    intrastate users. This concept also allows effective off-loading of
    user administration costs back to the provider.

2)  Those vetted subscribers are trusted users across the enterprise.
    The user experience is improved because users can navigate easily
    between resources while maintaining a global log-in identity.
    Authorized individuals have access to the resources they need
    regardless of where they reside.

3)  The service providers, CISAnet state agencies, are ultimately
    responsible for what information is provided. The federated model
    enables service providers to share and control resources to a large
    base of established users and partners that would normally not have
    access.

4)  Programs can agree on the information (metadata) that is to be
    shared. Integration is also simplified because there is a common way
    to network identities between agencies or between applications.

5)  Program organizations can eliminate the debates caused by
    incompatible identity and security management mechanisms.
    Demonstrating success will allow disparate programs to share
    information without adding excessive costs or losing their autonomy.

We are comfortable with the current direction of the GFIPM demonstration
project---the agreements reached by the participating programs---and
feel confident that this project will be a tremendous success. The
project should continue on its current course, collect and publish
valuable lessons learned, and begin discussion on the project's
expansion (i.e., specifications and users) in a follow-up phase.

[^1]: The Burton Group, please see <http://www.burtongroup.com/>.

[^2]: OASIS, please see <http://www.oasis-open.org/home/index.php>.