What is the Federal ICAM Backend Attribute Exchange (BAE) v2?

The BAE is a standards based architecture and interface specification to securely obtain attributes of subjects (e.g. PIV and PIV-I card holders, federation members with a unique identifier), from authoritative sources, to make access control decisions and/or to do provisioning.

While the original BAE v1 specification was a theoretical whiteboard exercise, the v2 specification incorporates the hands-on protocol profiling lessons learned from an initial proof-of-concept implementation, as well as a follow-on end-to-end pilot implementation of a pull based access control architecture. As such the "BAE documentation set" consists of:

• BAE v2 Overview
• Federal ICAM Governance for BAE v2
• SAML 2.0 Identifier and Protocol Profiles for BAE v2
• SAML 2.0 Metadata Profile for BAE v2
• SPML 2.0 Read-Only Profile for BAE v2

The BAE architecture and interface specification defines a mechanism for implementing a pure attribute provider and is not in the business of authenticating an end-user. Take a look at my previous entry on FICAM Support for Identity Federation Flows to see how the BAE v2 architecture fits in with the larger Authentication, Attribute Exchange and Authorization mechanisms.

To keep this focus on Attribute Provider functionality, I have started using the term BAE-AP (BAE Compliant Attribute Provider) to refer to an attribute service that implements the BAE protocol profiles.

As you can see in the documentation breakdown above, an implementation of a BAE-AP supports both the real-time, on demand, querying of attributes of a single person using SAML 2.0, and a "batch" read-only mechanism to retrieve attributes of multiple people using SPML.  The latter capability is important to satisfy many of the occasionally-connected and dynamic provisioning use cases that exist within the community.

The SAML 2.0 Profiles are fully baked while the SPML Profile is currently being developed as part of a Pilot.

There were some specific choices made in developing the BAE v2:

• The most important was to make sure that there were no dependencies between the Governance mechanisms and the implementation of the technical profiles. The Governance document illustrates how Federal ICAM will implement the BAE environment as an example. But organizations that are outside the Federal Government or Agencies and Departments who wish to implement a BAE-AP internally are free to utilize their own Governance mechanisms.
• During the development of the SAML profiles and the subsequent implementations, my team actively reached out to multiple forward-leaning vendors in this space and built a business case with each of them as to why they should support the BAE-AP profiles within their product set. We also stood up a reference implementation that is being used for interoperability and conformance testing. I am happy to note that products from Layer 7, Vordel and Intel currently have built in support for generating a BAE-AP SAML Attribute Service, and that  External Authorization Management (PDP) vendors such as BiTKOO and others have built in the capability to query a BAE-AP SAML end-point directly from their PDP.
• Last, but not least for the SAML profiles, we consciously separated the profiling of the Identifiers from the profiling of the Protocol which will allow anyone to snap-in additional identifiers as needed without impacting or changing the protocol profile. What that means in generic terms is that while the current SAML profile explicitly profiles the usage of a Subject DN from an X.509 Certificate,  FASC-N from a PIV Authentication Certificate or a UUID from a PIV-I Certificate to query a BAE-AP, you are free to extend what "key/Subject Name Identifier" you can use to query a BAE-AP. For e.g. Our reference implementation currently supports, in addition to the above, e-mail address and JID (Jabber ID) as identifiers that can be used to query for attributes. We simply advertise, within the metadata, the Subject Name Identifiers that are supported by our implementation of the BAE-AP. The expectation is that the Governance mechanism for a particular community will define the minimal set of Subject Name Identifiers everyone must support, but individual BAE-APs will be free to go beyond the minimal set given their particular use cases.

The Federal ICAM Architecture Working Group is in the process of reviewing and incorporating the comments from multiple parties, and once approved by the ICAMSC, the BAE v2 architecture and specification will become the US Federal Government's standard way to exchange attributes if using the "back-channel".