FAQs
The table below addresses roles and responsibilities from a GFIPM organizational standpoint.
|
GFIPM Organizational Roles and Responsibilities |
|
|
Role |
Responsibilities |
|
Federation Manager Organization (FMO) |
1. Vet prospective federation member organizations for membership. 2. Provide authentication credentials to member organizations. 3. Provide mechanism for authenticating member organizations. |
|
Identity Provider Organization (IDPO) |
1. Vet end users for access to the federation. 2. Provide authentication credentials to end users. 3. Authenticate end users. 4. Generate user assertions containing GFIPM metadata. |
|
Service Provider Organization (SPO) |
1. Provide application-level services to federation end users. 2. Perform access control based on GFIPM metadata. |
|
Trusted Identity Broker Organization (TIBO) |
1. Vet brokered IDPOs and their IDPs. 2. Represent brokered IDPs to the federation. 3. Generate user assertions containing GFIPM metadata on behalf of users from brokered IDPs. |
The table below addresses roles and responsibilities from a GFIPM Technical standpoint.
|
GFIPM Technical Roles and Responsibilities |
|
|
Role |
Responsibilities |
|
Certificate Authority (CA) |
1. Sign cryptographic certificates for member systems. 2. Sign the GFIPM Cryptographic Trust Fabric document. 3. Distribute the GFIPM Cryptographic Trust Fabric document to all member organizations. |
|
Identity Provider (IDP) |
1. Perform authentication for end users. 2. Generate SAML assertions containing GFIPM metadata about users. 3. Conform to the GFIPM Web Browser User-to-System Profile. |
|
SAML Service Provider (SP)1 |
1. Provide Web-based access to application-level services for end users. 2. Enforce resource access control policies based on GFIPM metadata from IDPs. 3. Conform to the GFIPM Web Browser User-to-System Profile. |
|
Web Service Consumer (WSC) |
1. Provide a connecting point through which a member organization can connect to GFIPM Web Services providers (WSPs). 2. Conform to the GFIPM Web Services System-to-System Profile. |
|
Web Service Provider (WSP) |
1. Provide Web Services-based access to application-level services for member organizations and their end users. 2. Conform to the GFIPM Web Services System-to-System Profile. |
|
Authorization Service (AS) |
1. Make authorization decisions on behalf of other GFIPM Web Services providers (WSPs) and issue tokens that can be used at those WSPs. 2. Conform to the GFIPM Web Services System-to-System Profile. |
|
Validation Service (VS) |
1. Provide validation of tokens, including GFIPM User Assertions, on behalf of other GFIPM Web Services providers (WSPs). 2. Conform to the GFIPM Web Services System-to-System Profile. |
|
Trusted Identity Broker (TIB) |
1. Generate SAML assertions containing GFIPM metadata about users from brokered IDPs. 2. Conform to the GFIPM Web Browser User-to-System Profile. |
The table below illustrates how the set of GFIPM organizational roles maps onto the set of GFIPM technical roles.
|
GFIPM Organizational Role Mapping to GFIPM Technical Roles |
|
|
Organizational Role |
Technical Roles |
|
Federation Manager Organization (FMO) |
Certificate Authority (CA) |
|
Identity Provider Organization (IDPO) |
Identity Provider (IDP) |
|
Service Provider Organization (SPO) |
SAML Service Provider (SP) Web Service Consumer (WSC) Web Service Provider (WSP) Authorization Service (AS) Validation Service (VS) |
|
Trusted Identity Broker Organization (TIBO) |
Trusted Identity Broker (TIB) |
The table below contains a “Terminology Map” that provides a concise comparison between GFIPM and several other prominent identity management paradigms in terms of what terminology is used to express various aspects of each paradigm.
|
GFIPM Service-Oriented Architecture Terminology Map |
|||
|
GFIPM |
SAML |
WS-*/WS-I |
JRA |
|
Organizational Roles |
|||
|
Federation Manager Organization (FMO) |
N/A |
N/A |
N/A |
|
IDP Organization (IDPO) |
N/A |
N/A |
N/A |
|
SP Organization (SPO) |
N/A |
N/A |
N/A |
|
TIB Organization (TIBO) |
N/A |
N/A |
N/A |
|
Technical Roles |
|||
|
Certificate Authority (CA) |
N/A |
N/A |
N/A |
|
Identity Provider (IDP) |
Same as GFIPM |
WS-Federation: Security Token Service in the role of IDP or Security Token Service in the role of Attribute Service |
Service Provider |
|
SAML Service Provider (SP) |
Service Provider |
N/A |
Service Provider |
|
Web Service Consumer (WSC) |
N/A |
WS-Federation: Requestor |
Service Consumer |
|
Web Service Provider (WSP) |
N/A |
WS-Federation: Resource |
Service Provider |
|
Authorization Service (AS) |
N/A |
WS-Federation: Security Token Service in the role of Authorization Service |
Service Provider |
|
Validation Service (VS) |
N/A |
WS-Federation: Security Token Service in the role of Validation Service |
Service Provider |
|
Trusted Identity Broker (TIB) |
N/A |
N/A |
Service Provider |
GFIPM Points of Contact
- Global Security Working Group
Mr. John Ruegg
Los Angeles County Information Systems Advisory Body
[email protected]
- GFIPM Delivery Team
Mr. John Ruegg
Los Angeles County Information Systems Advisory Body
[email protected]
Mr. James Dyche
Pennsylvania Justice Network
[email protected]
The value of GFIPM at a glance include:
- Improves privacy and security
- Significant cost savings
- Reduces administrative burden
- Fewer user credentials per user
- Distributed and highly scalable
- Reduces complexity of systems
It is a document via which information is delivered to GFIPM federation participants, which defines the most current cryptographic security context of the federation. The document contains an entry for each communications endpoint in the federation, including identity providers (IDPs), service providers (SPs), Web Service consumers (WSCs), Web Service providers (WSPs), and others.
For further details, see GFIPM Cryptographic Trust Model Document
GFIPM uses a standardized XML credential as the key part of federated identity to be used by members and partners of the justice community. Using the GFIPM credential will allow information to be shared in a new way-with reduced management burden and improved security and on a broader scale. It represents a strategic change and dramatic improvement in the way justice organizations establish the electronic trust needed to share information.
At the highest level of concept within the GFIPM model, there are three vital components that must interact between users of multiple systems:
Identity Provider (IDP)
Service Provider (SP)
User Credential Assertions (Metadata)
Within a federation, organizations play one or both of two roles: identity provider and/or service provider. The identity provider is the authoritative entity responsible for authenticating an end user and asserting an identity for that user in a trusted fashion to trusted partners. The identity provider is responsible for account creation, provisioning, password management, and general account management. This may be achieved with existing locally accepted security mechanisms and tools.
Federation partners who offer services or share resources are known as service providers. The service provider relies on the identity provider to assert information about a user via an electronic user credential, leaving the service provider to manage access control and dissemination based on a trusted set of user credential assertions. As mentioned above, an organization that is a service provider can also be an identity provider.
For further details, see GFIPM Overview or download the PDF file below for offline reading.
Because the GRA takes a services approach to information sharing, it incorporates and reuses appropriate subsets of the National Information Exchange Model (NIEM), Global Federated Identity and Privilege Management (GFIPM), and Global privacy products. It is also being used to produce compliant services for fusion centers that address challenges identified by the Global Intelligence Working Group and Criminal Intelligence Coordinating Council (CICC). The GRA supports national programs such as the Federal Bureau of Investigation’s Law Enforcement National Data Exchange (N-DEx), which also uses NIEM as a common data format. The GRA is directly related to other Global/federal initiatives, including NIEM and GFIPM, and, in fact, provides practitioners with overarching guidance that demonstrates how these initiatives work together.
The Services Task Team effort, a BJA-sponsored working group, is charged with implementing the Global GRA by producing reference service specifications for fusion centers, biometrics exchanges, and other future services to be determined. These specifications will further show alignment with national strategies and projects.
Global Reference Architecture (GRA) is a service-oriented reference architecture for justice and public safety information sharing. It is an information exchange solution designed to cut 80 percent of implementation time and costs for state and local justice agencies through reuse of established promising practices in IT architecture and design. GRA adheres to the principles of service-oriented architecture (SOA) and it is the culmination of Global's efforts to follow through on the recommendation of adopting SOA as the standard approach to justice and public information sharing. A jurisdiction that develops an information sharing architecture based on the GRA-by explicitly adopting and following a service-oriented architecture in alignment with Global's recommendation.
Source: A Framework for Justice Information Sharing: Service-Oriented Architecture (SOA).
The Global Reference Architecture (GRA) addresses various areas in the implementation of information exchange. Together, these areas form critical components of a comprehensive, replicable, and scalable solution to information sharing that balances varied technologies with dynamic policy considerations:
Reference Architecture Planning
The GRA includes recommendations for technical implementation that leverage Service Oriented Architecture concepts, customized for the justice domain. GRA addresses the full range of information sharing use cases by providing a flexible blueprint for implementing interoperable data sharing services across both technologically advanced organizations and those with limited technology resources. Guidelines for beginning implementation projects are available.
Service Specification Packages
GRA solutions to information exchange are made up of a combination of the connection method (often Web Services), the exchange language (use of NIEM is encouraged), and the security specifications (encryption at the transport layer, data layer, etc.). These specifications are packaged into a GRA solution that can be customized to meet an individual organization’s needs. A repository of Reference Service Specification Packages (SSPs) for information exchange in the justice community is being established; however, individual Reference SSPs are available in the interim.
Technical Implementation Guidance
Integrating a Reference Service Specifications Package (SSP) into existing IT infrastructure, despite the level of customization available in a Reference SSP, can involve a learning curve for those new to the implementation of GRA. Technical guidance regarding the GRA specification itself, as well as various guides on the interaction of different services and other aspects of information exchange, are available. In addition, personal assistance in implementing GRA is available through a number of valuable resources. See the Implementation Assistance section for more information.
Policy Guidance
In coordination with the technical implementation of a GRA Reference Service Specification Package, policy-level documents guide interaction between the agencies exchanging information. Examples include Service Level Agreements (SLA), access and identity management specifications, Memoranda of Understanding (MOUs), and many others. While these documents are never specific to GRA implementations, some specific resources available may be helpful in policy agreements. Source:
Source: https://bja.ojp.gov/program/it/national-initiatives/gra
The document - Global Reference Architecture REST Technical Note provides information regarding the compatibility issues between GRA and REST. See document link below.
Link: https://bja.ojp.gov/sites/g/files/xyckuh186/files/media/document/Global…
Resources available for GRA implementation are listed below:
Reference Architecture Planning
GRA Framework v1.9
GRA Guidelines for Identifying and Designing Services v1.1
GRA Service Specification Guideline, Working Draft v0.9.7
Reference Service Specification Packages (SSPs)
Arrest Warrant Information Exchange (AWIE) Service Specification, Working Draft v0.9.6
Fingerprint (FP) Service Specification, Working Draft v0.9.3
Inmate Release Information (IRI) Service Specification, Working Draft v0.9.4
Request for Information (RFI) Service Specification, Working Draft v0.9.2
Submit Suspicious Activity (SSA) Field Interview Report (FIR) Service Specification, Draft v.0.9.5
Submit Suspicious Activity (SSA) Suspicious Activity Report (SAR) Service Specification Draft v.0.9.5
Terrorist Screening Center Encounter Information (TSCEI) Service Specification, Draft v.0.9.4
Technical Documents
GRA Specification v1.8
GRA Service Specification Package, Working Draft v0.9.7
GRA Execution Context Guidelines v1.1
GRA Web-Services Service Interaction Profile v1.3
GRA ebXML Messaging Service Interaction Profile v1.1
GRA Reliable Secure Web Services, Service Interaction Profile v1.1
Policy Documents
GRA Information Sharing Enterprise Statement of Participation v1.1
GRA Information Sharing Enterprise Service-Level Agreement v1.1
Source: https://bja.ojp.gov/program/it/national-initiatives/gra
GRA defines a service interface as "the means for interacting with a service." It includes the specific protocols, commands, and information exchange by which actions are initiated on the service. A service interface is what a system designer or implementer (programmer) uses to design or build executable software that interacts with the service. Since the service interface is the physical manifestation of the service, best practices call for a service interface which can be described in an open-standard, referenced format.
Service Specifications support the two (2) primary use cases of the GRA, which are:
1. To provide the justice information sharing community with an architecture and supporting specifications and guidance such that practitioners can implement SOA more efficiently. As such, the JRA and related documents provide an 80 percent solution that eliminates the need for individual justice practitioners to invent their SOA solutions from scratch and enhances the likelihood of reuse.
2. To provide a framework within which the JRA can be maintained and enhanced and national reference services can be developed to enhance interoperability.