Information Sharing and Cybersecurity are hot button topics in the Government right now and Identity, Credentialing and Access Management are a core component of both those areas. As such, I thought it would be interesting to take a look at how the US Federal Government’s Identity, Credentialing and Access Management (ICAM) efforts around identity federation map into the Authentication, Attribute Exposure and Authorization flows that I have blogged about previously.
[As I have noted before, the entries in my blog are solely my opinions and do not represent the thoughts, intentions, plans or strategies of any third party, including my employer, except where explicitly stated. As such, what I am about to say is simply my informed opinion and may or may not be what the FICAM Gov’t folks intent or believe]
When I think of the components of Identity Federation, I tend to bucket them into the 3 P’s; Protocol, Payload and Policy:
What are the technical means agreed to by all parties in a federation by which information is exchanged? This will typically involve decisions regarding choices and interoperability profiles that relate to HTTP, SOAP, SAML, WS-Federation, OpenID, Information Cards etc. In the past I’ve also referred to this as the “Plumbing”. ICAM calls these “Identity Schemes”.
Federal ICAM Support for Authentication Flows
- Brokered I (Federated) and Brokered II (Federated) flows are supported at LOA 1, 2 and Non-PKI 3 using the ICAM OpenID 2.0 Profile [PDF], ICAM IMI 1.0 Profile [PDF], Kantara eGov 1.5 Profile [PDF] and the ICAM SAML 2.0 Web Browser SSO Profile [PDF]
- Brokered II (Federated) flow is supported at LOA 3 and LOA 4 by usage of the Federal PKI Bridge with PKI infrastructures issuing PIV Cards for Federal Government entities and PIV-I Cards [PDF] for Non-Federal and Commercial entities
Federal ICAM Support for Attribute Exposure Flows
- Organizational Query and Single Point of Query 1 flows are supported by the ICAM SAML 2.0 Web Browser SSO Profile [PDF]
- Organizational Query, Single Point of Query 1, Single Point of Query 2 and Identity Oracle flows are supported by the ICAM Backend Attribute Exchange (BAE)*
Federal ICAM Support for Authorization Flows
- Front Channel Attribute Based Access Control (ABAC) flow is supported by the ICAM IMI 1.0 Profile [PDF] and the ICAM SAML 2.0 Web Browser SSO Profile [PDF]
- Back Channel ABAC flow is supported by ICAM Backend Attribute Exchange* (BAE)
What is carried on the wire? This typically involves attribute contracts that define how a subject may be defined, the additional attributes needed in order to make access control decisions etc.
Federal ICAM Support
ICAM remains agnostic to the payload and leaves it up to the organizations and communities of interest that are utilizing the ICAM profiles to define their attribute contracts.
In Appendix A of the ICAM Backend Attribute Exchange* (BAE) (v1) there was an attempt made to define the semantics of a Federal Government wide Attribute Contract but none of the attributes are required. Currently there is a Data Attribute Tiger Team that has been stood up under the ICAMSC Federation Interoperability Working Group which is working to define multiple attribute contracts that can potentially be used as part of an Attribute Exposure mechanism.
The governance processes that are put into place to manage and operate a federation as well as adjudicate issues that may come up. In the past I’ve referred to this as “Governance” but thought that Policy may be much more appropriate.
Federal ICAM Support
- Which protocol is supported by ICAM is governed by the FICAM Identity Scheme Adoption Process [PDF]. Currently supported protocols include, OpenID, IMI and SAML 2.0.
- FICAM, thru its Open Identity Initiative, has put into place a layer of abstraction regarding the certification and accreditation of non Government Identity Providers allowed to issue credentials that can be utilized to access Government resources. This layer is known as a Trust Framework Provider. The Trust Framework Providers are responsible for assessing non Government Identity Providers (IDPs). The process by which an Organization becomes a Trust Framework Provider is known as the Trust Framework Provider Adoption Process [PDF]. Currently supported Trust Framework Providers include OIX and Kantara.
The ICAM Backend Attribute Exchange (BAE) v1.0 [PDF] document that I am linking to here is rather out of date. The Architecture components of this documents are still valid but the technical profile pieces have been OBE (Overcome By Events) and are significantly out of date. The ICAMSC Architecture Working Group is currently working on v2 of this document incorporating the lessons learned from multiple pilots between Government Agencies/Departments as well as implementation experience from COTS vendors such as Layer 7, Vordel and BiTKOO who have implemented BAE support in their products. Ping me directly if you need further info.
Did you find this interesting? Don't miss any new posts. Sign up to automatically receive them now!
This blog post first appeared on Anil John | Blog (https://blog.aniljohn.com). The opinions expressed here are my own and do not represent my employer’s view in any way.