How to Discover Resources in NIEF - Revision history

Jeff.Krug: Replaced content with "{| !class="gfipmnav"|Go back |} Review [https://nief.org/nief-services/ NIEF resources] as we..."

2019-01-17T19:30:08Z

Replaced content with "{| !class="gfipmnav"|Go back |} Review [https://nief.org/nief-services/ NIEF resources] as we..."

@@ Line 1: / Line 1: @@
 {|
-!class="gfipmnav"|[[How to Develop a GFIPM Information Sharing Plan for an Identity Provider|Go back]]
+!class="gfipmnav"|[[How to Develop a NIEF Information Sharing Plan for an Identity Provider|Go back]]
 |}
-This article guides you through the process of discovering available resources in your federation and determining which of them may be of value to your organization's users. Additionally, you need to consider the future as your federation adds more Service Providers with more and more resources. You will want your users to have access to the appropriate resources in the future, preferably without having to add capabilities to your IDP. At the end of this section, you should have a list of access control policies for which your users need to qualify. This list will be used in subsequent sections to help you implement an IDP that can assert the appropriate metadata.
+Review [https://nief.org/nief-services/ NIEF resources] as well as the [https://nief.org/trust-fabric/ trust fabric] to identify potential information sharing partners.
-The following steps will help you accomplish the above goals:
+== Review Access Control Policy Attributes ==
-# Survey the current landscape of available federation resources.
+== Review Required Trust Interoperability Profiles ==
-# Determine which existing resources would be of value to your users. Also consider what other future resources you might want for your users and what the access requirements for those resources might be.
+TBD.  In theory one could review the TIPs for planned partners, but this information is not currently published.
 {|
-!class="gfipmnav"|[[How to Develop a GFIPM Information Sharing Plan for an Identity Provider|Go back]]
+!class="gfipmnav"|[[How to Develop a NIEF Information Sharing Plan for an Identity Provider|Go back]]
 |}

Jeff.Krug: Created page with "{| !class="gfipmnav"|Go back |} This article guides you through the process of discovering avail..."

2019-01-17T19:24:11Z

Created page with "{| !class="gfipmnav"|Go back |} This article guides you through the process of discovering avail..."

New page

{|
!class="gfipmnav"|[[How to Develop a GFIPM Information Sharing Plan for an Identity Provider|Go back]]
|}

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

The following steps will help you accomplish the above goals:

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

To explain these concepts and help you put them into action, [https://nief.gfipm.net/ NIEF] resources are used as examples throughout this section.

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

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

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

'''Resource Example 1'''

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

'''Access Control Policy'''

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

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

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

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

'''Resource Example 2'''

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

'''Access Control Policy'''

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

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

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

OR

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

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

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

'''Resource Example 3'''

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

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

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

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

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

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

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

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

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

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

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

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

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

{|
!class="gfipmnav"|[[How to Develop a GFIPM Information Sharing Plan for an Identity Provider|Go back]]
|}