GSA OGP, together with our partner PM-ISE, is moving out on the operational deployment of the FICAM Backend Attribute Exchange (BAE). The PM-ISE blog post "A Detailed Test Scenario for our Law Enforcement Backend Attribute Exchange Pilot" gives details about our primary use case. In this blog post, I am going to map those business and information sharing aspects to some of the technical details of the deployment.
The operational scenario looks like this:
In any such scenario, there are always three parties to the transaction. An Identity Provider, a Relying Party and an Attribute Provider.
"A law enforcement officer in Pennsylvania has an account on the Pennsylvania J-Net network, which supports many public safety, law enforcement, and state government agencies and mission communities. To obtain the J-Net account, the officer’s identity and status were vetted and various facts about identity, assignment, and qualifications were captured and maintained in the J-Net user database.
In the course of an investigation, the officer needs to access data on the RISS-Net system."
J-NET is the Identity Provider and RISS-Net Portal is the Relying Party.
"… both J-Net and RISS-Net are members of the National Information Exchange Federation (NIEF), RISS-Net can accept electronic credentials from J-Net once the officer logs into a J-Net account and is authenticated."
One of the primary reasons we are interested in this scenario (beyond the information sharing value of the deployed capability) is the existence of the NIEF Federation. NIEF already counts J-NET and RISS-NET as members. Which in turn means that there is an existing framework for collaboration and information sharing between them we can plug into, and enhance, with the BAE.
One of the critical technical benefits of this relationship, within the context of the BAE deployment, is that the Federation Identifier has been standardized across NIEF (gfipm:2.0:user:FederationId).
When we created the "SAML 2.0 Identifier and Protocol Profiles for BAE v2.0" (PDF), we deliberately separated out the profiling of the identifiers and the profiling of the protocols precisely so that we could "snap-in" new identifiers, without impacting the security of the protocol. We also put in some specific wording that allowed this flexibility; "It is expected that if credentials with [identifiers] other than what is profiled in this document are used in a BAE implementation, the Federation Operator governing that Community of Interest will define the profiles necessary for that credential type."
As part of this pilot, we will be defining an identifier profile for the NIEF Federation Identifier that will be used in the attribute query made to the BAE Attribute Service.
"RISS-Net has defined a policy for access to their information resources, which is expressed in terms of specific characteristics (“attributes”) of authenticated users. The RISS-Net policy requires that a user is certified as a “Law Enforcement Officer”, and has the necessary 28CFRPart 23 training."
The key to keep in mind is that the existing NIEF SAML Federation and the supporting information sharing framework already allows J-NET to assert the "Law Enforcement Officer" (LEO) attributes for their members when they go to access the RISS-Net Portal.
"… although the officer was trained on 28CFRPart23 in a course offered online by the Bureau of Justice Assistance (BJA), this fact is not part of the officer’s J-Net’s record (28CFRPart23 training status is not one of the facts gathered in their vetting process). Thus J-Net cannot provide all the credentials required by RISS-Net for access to the needed data."
And this is the critical value add for this pilot! There is additional information locked up within RISS-Net that can only be accessed if the 28CFRPart23 attribute is provided. J-Net is not able to assert this, but BJA as the authoritative attribute source can. And we are utilizing the BAE Shared Service Infrastructure deployed at GSA to provide them the capability to do so.
An item that we are still exploring is if the information that is available from the NIEF Federation Identifier as well as the J-NET Attribute Assertion gives enough information such that we can uniquely identify an existing record of a trained LEO at BJA. This is still an open question and is critical in making this work.
As you may have noted, I keep calling the deployment of the BAE Infrastructure at GSA a "Shared Service Infrastructure". That is a deliberate choice of words and I wil expand on that in the future, especially given that this is not our only pilot use case for the BAE deployment!
RELATED POSTS
- From AAES to BAE - Implementing Collection and Sharing of Identity Data
- PM-ISE: A Detailed Test Scenario for our Law Enforcement Backend Attribute Exchange Pilot
- Shared Services and Government as Attribute Service Provider
- PM-ISE: Advancing Identity Access Management (IdAM) with a Pilot Project in Pennsylvania
:- by Anil John
