The Backend Attribute Exchange (BAE) Capability implements a pure Attribute Provider and, by deliberate design, does not provide any authentication functionality. The current technical implementation of the BAE supports a secure FICAM Profile of SAML 2.0 Assertion Query and Response (PDF) which is bound to SOAP. In this blog post, and as a thought exercise, I am going to walk through some of the approaches, considerations and use cases in how we could extend the BAE to support additional protocols for attribute exchange.
XACML
XACML is a protocol that is well understood by the Government community and at v3.0 is a mature standard that has support in multiple COTS products. The use case that I am envisioning is driven more by the need to provide a capability to verify self-asserted attributes rather than pure attribute retrieval:
- An entity needs to ask a question and asserts a set of attributes in support of that question . e.g. "Is this person allowed to drive a car in Maryland?" + Data found on a Driver's License
- There are privacy and/or data security concerns regarding the attributes such that the attribute provider cannot respond with the verified attribute values from the authoritative source
- The attribute provider responds with a boolean "Yes|No" and clarification/error data as appropriate
In order to accomplish this, you could profile XACML messages on the wire, NOT for Authorization, but to construct a verification request and a corresponding response given that XACML 3.0 provides:
- The ability to send multiple attributes and values in and the ability to get a Yes|No or a Match|NoMatch decision back
- Attribute Categories (pre-defined and custom) for <Subject>, which can carry the self-asserted attributes of the subject, and <Resource>, which can be used to route the request to the appropriate authoritative sources
- The request message allows for capturing the consent of the <Subject> for attribute release
- XACML Advice that can be returned to inform the requester of errors (Don't want to use obligations here given that the standard requires that PEP must discharge obligations)
- Ability to layer in cross-cutting security functionality, at both the message and transport level using existing infrastructure
The BAE could potentially support this as an additional interface that can in effect act as the technical pieces of an Identity Oracle.
OAUTH 2
OAUTH 2 is a new protocol which, in my mind, has relevance to the Government community because of how it could be utilized to layer in identity into mobile devices. This use case is more about implementing a pure Attribute Provider functionality using a profile of OAUTH 2 rather than supporting the full OAUTH 2 IdP functionality.
If you take a look at the work that has been done on OpenID Connect (OIDC) as an example, they have defined what is called a UserInfo Endpoint. This endpoint is simply an OAUTH 2 Protected Resource with some specific communication semantics:
- It requires that an Access Token be sent to it (i.e. UserInfo Request is sent as an OAUTH2 Bearer Token)
- It returns attributes in cleartext JSON or if needed as a signed/encrypted JWT (i.e. UserInfo Response)
One thing I am currently not sure about is if the OpenID Connect specification constrains in any way the implementation of the UserInfo Endpoint to the OIDC Identity Provider (i.e. the entity that actually authenticates the end user), or if it in practice can provide a flow/ability to support a "stand-alone" UserInfo endpoint.
The BAE could potentially support this as an additional Attribute Provider interface, and depending on the Authorization Server (OpenID Connect) or Authorization Manager (UMA) based OAUTH 2 flows, could support the appropriate semantics in the request and response.
Comments and perspectives on both are welcome!
RELATED POSTS
- From AAES to BAE - Implementing Collection and Sharing of Identity Data
- What is new with the BAE Operational Deployment?
- Shared Services and Government as Attribute Service Provider
:- by Anil John
