Privacy Preserving Attribute Verification using XACML

I've always considered Attribute Providers to be a first class citizens of an Identity Ecosystem that are  distinct and separate from Identity Providers. But as we move into an era where identity assurance becomes more critical for high assurance online transactions, a use case that is becoming main stream is the verification of self-asserted attributes rather than pure attribute retrieval.

The use case goes something like this:

1. A person needs to complete a transaction with a (commercial) entity (Obtain a high assurance credential, Open an account etc.)
2. Person self-asserts a set of claims/attributes; this may be via documents or electronic; in person or remote
3. The authoritative source of the claims/attributes is typically not a commercial entity. e.g. Federal Government and/or State Government Agencies where there are significant privacy implications to the release of this data to commercial entities who may re-sell this information or use it for non-authorized secondary purposes

The ability to interact with these authoritative sources requires more than simple connectivity given the privacy implications of the data, so how can this transaction be completed in a manner that satisfies the needs of all parties?

This, of course, is the classic case of Government as an Attribute Provider but with a twist in that the use case is not looking at retrieving attributes in order to make access control decisions, but about verifying self-asserted attributes for purpose X. The aspects that need to be kept in mind when looking at this use case, at least in the United States, are:

• Federal Government Agencies consider citizen information to be highly sensitive from a privacy perspective and are very leery of releasing that information even to other government agencies. Commercial entities have an even higher bar to cross
• The authoritative source is typically not allowed to release actual attribute/claim values due to regulatory and/or privacy policy constraints 
• The only potential way to thread this minefield would be if there is a policy that supports the release of this information for a clear authorized purpose with no other downstream re-use for any other purpose. If so, an option they will typically entertain is to return information that verifies the value of a self-asserted claim. i.e. An Agency can provide a [yes|no] answer regarding a comparison match result between a self-asserted claim and what they have in the system for that person, but not much more.
• To make this scale across sectors and authoritative sources, not to mention the lack of desire to build custom/proprietary interfaces, there needs to be some standardization of the technical interfaces that are used to complete this transaction. 

I am, for now, going to put aside the justification that needs to be built in order to support the authorized purpose policy and am going to focus purely on the technical aspects. Some of the criteria I was considering were:

• Do NOT want to reinvent the wheel by coming up with an API or interface that is bright/shiny/new; the folks that this needs to appeal to are the no-nonsense types that like to minimize the number of moving parts they need to manage in their Enterprise, and are highly concerned about security and policy compliance
• Would like to leverage an existing and standardized protocol standard
• Would like to have support for that standard in existing infrastructure elements that may already be deployed

Initially I was looking at SAML as a potential solution, but that does not map well to this use case. The SAML AttributeQuery requires that the subject be clearly identified (typically via some sort of authentication step), but in thinking a bit more about this, it looks like XACML 3.0 may very well address the need more cleanly.

I want to emphasize that what is being proposed is not using XACML for Authorization but simply using the standardization and capabilities of XACML messages on the wire as a mechanism to fulfill a particular purpose which may potentially torque off the purists. As such XACML 3.0 provides:

• 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.
• 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)
• Commercial implementation of XACML Externalized Authorization Managers that have the ability to call out to external attribute sources using LDAP(S), SAML, JDBC/ODBC, Web Services etc. And if not, it would be relatively straight forward to integrate the engine with a Virtual Directory Infrastructure to provide this capability.
• XACML Compliant Decisioning Engines that can be used to do attribute matching based on clearly defined and verifiable policies.
• Ability to layer in cross-cutting security functionality, at both the message and transport level using existing infrastructure

I ran this by some smart folks that I know of in the community and the conversation survived the questions and issues that were brought up. To take this to its natural conclusion would potentially require work to define an "Attribute Verification Profile of XACML 3.0". But ultimately, I would also throw this in the ring as a potential way to implement the technical aspects of an Identity Oracle. Comments?

UPDATE (12/30/11): @NishantK brought up a great point that I wanted to highlight given the privacy concerns. The request message format allows for capturing the consent of the subject for attribute release, which it turn can be used to drive the go/no-go at the decision engine.

Related Posts:

• Identity Oracles and their role in the Identity Eco-System
• Identity Oracles - Trust is Ephemeral, Contracts are Eternal

User Consent in the Age of Attributes

An interesting, and often frustrating, conversation that takes place in the federated identity and authorization space revolves around obtaining the consent of the user, in real time, for attribute release and who exactly is responsible for doing so. Is it the responsibility of the Identity Provider (IdP) to get the consent and release only those attributes that are necessary for a transaction, or is it the responsibility of the Relying Party (RP) to notify the user as to its needs for attributes? And what is the role of the Attribute Provider (AP) which may very well be a separate entity from the IdP and the RP?

To begin, this conversation really needs to revolve around the needs of the consumer and what they are willing to provide to a service provider to obtain a service, and what the service provider needs from the consumer in order to fulfill that service.  The following graphic depicts the various intersections of what an IdP/AP can provide and what an RP needs, with the sweet-spot being the upper right quadrant.

The challenge in the current state of affairs is that there is a distinct lack of visibility for the consumer at run-time/real-time in what is provided by the IdP/RP on their behalf and what is being asked for by the service provider to provide a service to them, which limits their ability to make an informed choice.  Current implementations typically show one side or the other and often defer to protocol support to even offer that choice. To get to where we need to, the user experience in providing that visibility needs to remain consistently understandable across protocols, platforms and user interfaces.

I believe that what we need is something that sits "in the middle" of the IdP-AP-RP transaction troika and surfaces to the consumer information about them that is available and/or requested, and asks them to make explicit choices as to what they are willing to share about themselves in order to obtain a service. And since I don't want to keep calling it "the-thing-in-the-middle", I name it Attribute Chooser!

Given below is a UI mock-up of what the Attribute Chooser could look like:

Attribute Chooser UI

Starting with top right quadrant, you can see that NAME, EMAIL, ADDRESS and MOBILE number are available from the IdP/AP. NAME and EMAIL are required by the RP in order to complete the transaction, but the decision to provide the ADDRESS and MOBILE number are up to the Consumer.

The top left quadrant lets the Consumer know that the IdP/RP is also providing information such as HOME PHONE, JOB TITLE and LIKES (a clear case of sharing far too much information and something the Consumer may want to tighten up if possible at the IdP/AP). But it is also made clear to the Consumer that this information is NOT requested or collected by the RP.

The bottom right quadrant notes two pieces of information, NIST LOA and EMPLOYER, that the RP would like to have but is not provided by the existing IdPs/APs.

It truly does not matter who implements this capability. It could be the IdP, the AP, the RP or even a third party service subscribed to by the consumer such as an Identity Oracle. What I do know is that, given that Privacy issues more are more are having real impact on bottom-line business results, we need something like this that allows us to operationalize Privacy.

Reality of XACML PEP-PDP Interoperability - Part III

The OASIS XACML TC is currently updating the "SAML 2.0 Profile of XACML" to Version 2.0 and seeking public comments. This is a good thing!

There are many pieces to this Profile, but to me, the two most relevant are:

1. Using the standard <samlp:AttributeQuery> and <samlp:Response> to give a PDP (or a PEP) the ability to query and retrieve attributes from a SAML 2.0 compliant attribute provider. 
2. Using the SAML 2.0 Assertion and Protocol mechanism to define a standardized, profiled, multi-platform and multi-language supported mechanism for how a XACML Policy Enforcement Point (PEP) can request an authorization decision from a XACML Policy Decision Point (PDP), and how that PDP can respond with the decision to the PEP.

(1) is something that is critically important to support, at the PDP, for cross-organizational attribute retrieval for Attribute Based Access Control (ABAC). I have spoken about this before, so won't belabor the point again.

The importance of (2) was part of a disturbance in the tweet-force initiated by Paul Madsen and Ian Glazer last week that brought out what I believe is the primary use case for this section of the profile; Interoperability in XACML PEP/PDP communications across vendor solutions. 

I've written about both the need for this, as well as the vendor support in the past (Reality of XACML PEP-PDP Interoperability - Part I, Reality of XACML PEP-PDP Interoperability - Part II) so won't duplicate the reasoning here. But it is worthwhile to note some of the standardization pieces in the profile:

As you can see above, SAML 2.0 is leveraged in this profile for XACML PEP/PDP communications in two ways:

• It defines a new SAML 2.0 extension element to the <samlp:RequestAbstractType> called the <xacml-samlp:XACMLAuthzDecisionQuery> that can be used "... by a PEP to submit an XACML Request Context, along with other optional information, as a SAML protocol query to an XACML Context Handler"
• It defines how the standard SAML 2.0 "... <samlp:Response> containing a  XACMLAuthzDecision Assertion MUST be used by an XACML Context Handler as the response to an <xacml-samlp:XACMLAuthzDecisionQuery>.  An instance of such a <samlp:Response> element is called an XACMLAuthzDecision Response in this Profile"

The promise of this work will only be fulfilled by the adoption of this profile by XACML PDP Vendors, XML Security Gateway Vendors that act as XACML PEPs, COTS Application vendors who build in hooks in their applications to externalize authorization, and Physical Access Control (PACS) vendors who would like to integrate policy driven enforcement into their product lines.

Now is the time for Enterprises, and solution providers to Enterprises, to point their vendors to this work and start incorporating this into your RFIs and RFPs going forward.

Related Posts

• Reality of XACML PEP-PDP Interoperability - Part I
• Reality of XACML PEP-PDP Interoperability - Part II
• Converging Logical and Physical Access Control via XACML

Standards Compliance: Balancing Purity and Pragmatism

Standards are the new (again) bright and shiny objects in the sky. These days, beyond the work that is going on in the formal international standards development organizations, you can't turn around without tripping over vendor run consortiums or just groups of vendors getting together to develop a "standard" around something that is near and dear to them, or working to get community buy-in for something that has been developed internally by putting a "contributing-it-to-X-to-make-it-a-standard" label on the work.

Since I believe that a Standard without vendor adoption and implementation in products is nothing more than shelf-ware, I am pretty neutral about the variety of processes to get to that end goal, provided that there is opportunity for open participation by all interested parties in the development, and the end-product is open and re-usable to all without onerous licensing and/or IP restrictions attached to it.

Ultimately, standards commoditize the interfaces between systems, so from the perspective of an organization that is seeking to implement a capability to solve a business problem, how do you determine where standards matter and where they don't? How do you choose between two products that implement the same standard? Where role does agility and innovation play in this decision?

In order to answer all of these questions, the starting point is to properly define the boundaries that will determine where purity (i.e. Standards Compliance) rules, and where pragmatism (i.e. Implementation Flexibility) should be the primary consideration.

Balancing Purity and Pragmatism

Using the above diagram as a guide, one should place a priority on purity at the interfaces between systems deployed across organizational/sphere-of-responsibility boundaries. A concrete example of this would be in the case of an organization seeking to deploy a relying party web site (App B) that accepts federated credentials from an external Identity Provider (App A). It is critically important to use specific standards (or profiles of standards) in the communications between the User (agent), Identity Provider and Relying Party.

At the same time, within the organizational/sphere-of-responsibility boundary, one can be much more pragmatic about implementation. Extending the federated identity example noted above, the ability of the relying party web site (App B) to accept federated credentials will require the internal deployment of a Federation Engine (App B-1) and potentially an Externalized Authorization Manager / Entitlement Server (App B-2) to manage and enforce access control rules. The organization has the option of taking a much more pragmatic approach to how those three pieces talk to each other.

This pragmatic approach allows one to leverage vendor innovation and flexibility. Smart, capable and forward-leaning vendors realize that their products do not work in isolation and build in interfaces that ease integration with complementary products. They also realize that they have an opportunity to distinguish themselves from their peers by offering unique and value added capabilities to the Enterprise in their approach to integration. Some things that I can think of in the area of federated identity are supporting the surfacing of privacy constraints and attribute release rules to the end user, minimizing dependencies on third party products etc.

In short, by balancing purity and pragmatism, you are able to build and support an interoperable system while taking advantage of diversity and innovation.

Implications of US Gov Accepting Externally-Issued Credentials

The OMB Memo to US Government Departments and Agencies on "Requirements for Accepting Externally-Issued Identity Credentials [PDF]" has been signed and delivered.

What are some of the potential implications to some of the stakeholders impacted by this Memo?

Users of Government Web Sites

via the White House Blog:

"This memorandum marks a new day for Federal efficiency: a citizen who is a veteran, a college student and a taxpayer ought not to have to obtain separate digital credentials at each agency website, but instead should be able to use ones he or she already has – a university-issued credential for example - across sites hosted by the Departments of Veterans Affairs, Education and Treasury.  Doing so allows the Federal government to streamline the customer experience and recognize real cost savings just when we need to be tightening our belts. Moreover, by using accredited identity providers, Federal agencies see to it that Americans’ information is treated with privacy and security online." 

Government Public Web Site Owners

• You are the primary target audience for this memo; Any enhancements to existing sites or development of a new site triggers this requirement
• Update/Initiate a Risk Assessment to determine acceptable credentials for the web site
• Go through some variation of "HOW-TO: Fast Track to Federation for Web Sites"
• Update your Acquisition and RFP language for Federation Technology to require support for approved FICAM Protocol Profiles 
• Think hard about how you will implement an Authorization strategy on your web site
• Have questions? Need clarification on a specific point? Contact ICAM@gsa.gov. That will get you to the authoritative source of information about what you need to do, and what help is available for you.

Identity/Credential Providers

• Are you an OpenID 2.0 IdP? Are you a SAML 2.0 IdP? If so, do you implement support for the FICAM Protocol Profiles for OpenID 2.0 and SAML 2.0?
• Explore what it takes to get certified as an IdP, whose credentials can be used on Government web sites, by one of the FICAM Approved Trust Framework Providers
• What will it take for you to offer Credentials at LOA 2? 3? 4? Is there a need for it? Is there a market for it?
• Are you a PKI Vendor who can offer a PIV-I  (LOA 4) credential? Currently there is a gap in the commercial offerings that are available in offering high assurance credentials. Who are the communities of interest that need to inter-operate with the federal government, who need your  services? Health Care? Emergency Responders? State and Local Governments?

Federation Technology Vendors

• Build in explicit support for FICAM Approved Protocol Profiles on the IdP side and especially the RP side
• Expect to see RFP and Acquisition language that explicitly requires support for approved FICAM Protocol Profiles in your product portfolio
• (Thinking out loud: Remember how back in the day, the Liberty Alliance used to do SAML Interoperability Testing? Would it not be interesting and useful if Vendors or a Consortium stood up and did the same thing around FICAM Protocol Profiles? So that when you are having a conversation with a Government Agency or Department, you could point to the results for your product to verify compliance with what they are looking for)

External Authorization Management (a.k.a Fine Grained Authorization) Vendors

• Currently the majority of Government Agencies and Departments are focused almost exclusively on Authentication (HSPD-12, PIV, CAC, PIV-I and now OpenID 2.0 and SAML 2.0)
• This memo will, for better or worse, change that mind-set for one particular reason. As agencies and departments go through and do the risk assessment on their sites, they may very well come to the realization that they need to provide information at varying levels of sensitivity to a variety of customers, and that a one size fits all Authentication = = Authorization strategy is limiting at best.
• That will in turn trigger a need to implement an Authorization strategy in tandem with the Federation approach to make sure that the Agencies and Departments have the ability to provide the right data to the right people based on the authorities, roles and privileges of the those people.
• Expect to see changes in Acquisitions and RFPs to incorporate Attribute Based Access Control (ABAC) capabilities.
• If you don't already, explicitly start building in the capabilities to consume and act on attributes passed to you in the "front-channel" by a Federation Server, and the ability to retrieve attributes via the "back-channel" using the FICAM Backend Attribute Exchange.

US Gov public web sites required to accept federated credentials

On October 6, 2011, the US Federal CIO signed the OMB Memo "Requirements for Accepting Externally-Issued Identity Credentials [PDF]" that requires US Government public facing web sites to accept federated (non-Government, externally issued) credentials.

Highlights from the OMB Memo:

"To decrease the burden on users of our systems, and reduce costs associated with managing credentials, agencies are to begin leveraging externally-issued credentials, in addition to continuing to offer federally-issued credentials.

[...]

Effective 90 days following final approval of at least one Trust Framework Provider (identified in Attachment A), agencies are to begin implementing the new requirement that will result in full implementation over the next three years by taking the following actions:

• All new development of assurance Level 1 web sites that allow members of the public and business partners to register or log on must be enabled to accept externally-issued credentials in accordance with government-wide requirements.
• Existing assurance Level 1 web sites that allow members of the public and business partners to register or log on must include the requirement to accept externally-issued credentials in accordance with government-wide requirements when those sites are enhanced or upgraded.

Additionally, where appropriate and as resources permit, Levels 2, 3 and 4 websites that allow members of the public and business partners to register or log on should be enabled to accept externally-issued credentials at higher levels of identity assurance in accordance with government-wide requirements.

To ensure federal privacy and security requirements are addressed, agencies are required to follow Office of Management and Budget (OMB) policy and may only accept externally issued credentials that are issued in accordance with National Institute of Standards and Technology guidelines and Federal Chief Information Officers Council processes. Refer to Attachment A for the current list of approved providers. For existing web sites accepting non-approved externally-issued credentials, the agency must have an OMB/agency agreed-upon plan for complying with the requirement to use approved providers and schemes."

As you can imagine, this is a pretty big endorsement of Federated Identity by the US Government, and moves the ball forward significantly from the perspective of both FICAM and NSTIC. (I will provide a link to the official memo as soon as OMB puts it up on their web site.)

Resources and Related Posts

• OMB Memo: Requirements for Accepting Externally-Issued Identity Credentials [PDF]
• White House Blog: Advancing the National Strategy for Trusted Identities in Cyberspace: Government as Early Adopter
• Approved FICAM Trust Framework Providers, Identity Schemes and Identity Providers
• HOW-TO: Fast Track to Federation for Web Sites
• HOW-TO: Conduct a Risk Assessment to Determine Acceptable Credentials
• Implications of US Gov Accepting Externally-Issued Credentials

User Attributes - More than Identity

Mark Dixon's blog post on "User Attributes - Part of Identity?" talks to the point that attributes that make up a person's identity are not going to be located in just the main directory, but distributed across multiple repositories.

I completely agree with this point of view and think that architectural approaches such the "Pull Based Identity Architecture" and technical implementations such as the "FICAM Backend Attribute Exchange (BAE)" exist to pull together the fragmented and distributed aspects of a person's identity, at the moment of need, via a single point of query.

The clarification I would add is that when talking of User Attributes, it is often useful to make distinctions regarding what they are, and what they are used for. The model that I use is the following:

• Identity Attributes - Attributes of a person that are focused on identifying and/or authenticating a person. These are often attributes that are available on a credential.
• Authority Attributes - Attributes used to make access control decisions. These are authorities, licences, roles or privileges associated with a person that allow them access to physical and/or logical resources.
• Preference Attributes - Attributes that are related to user preferences, often self asserted, that allow the tailoring of displays and information.
• Environmental Attributes - Attributes that relate to the current status of the operational environment (Often not directly person related but relevant) and/or related to security aspects of how the person is coming into the system. e.g. Connecting via VPN or Current Threat Level

By separating User Attributes into these buckets, it immediately becomes obvious that there can be no single directory or repository (especially in large organizations) that can hold all of these attributes that make up a digital person.

Related Posts:

• Want ABAC? Across Organizations? Start with Policy!