My blog has moved and can now be found at http://blog.aniljohn.com

No action is needed on your part if you are already subscribed to this blog via e-mail or its syndication feed.

Friday, 22 October 2010
« Federation Flows 3 - Authorization | Main | Want ABAC? Across Organizations? Start w... »

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]

Fed_3Ps When I think of the components of Identity Federation, I tend to bucket them into the 3 P’s; Protocol, Payload and Policy:

  1. Protocol
    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

    Federal ICAM Support for Attribute Exposure Flows

    Federal ICAM Support for Authorization Flows


  2. Payload
    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) [PDF] 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.
  3. Policy
    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.

Technorati Tags: ,,,,,,,

del.icio.us Tags: ,,,,,,,
Tags:: Architecture | Security
10/22/2010 14:27 Eastern Daylight Time  |  Comments [0]  |  Disclaimer  |  Permalink   
Comments are closed.