Joint White Paper: Attribute-Based Access Control Solutions: Federating Authoritative User Data to Support Relying Party Authorization Decisions and Requirements Submitted Date: April 10, 2013 Submitted by: David Coxe, CEO, ID Dataweb, Inc. Co-Founder and SVP, Criterion Systems, Inc. 8330 Boone Blvd., Suite 400 Vienna, VA 22182 O: 703-942-5800, ext. 315 C: 571-332-2740 DCoxe@IDDataweb.com www.iddataweb.com Karyn Higa-Smith, Program Manager Science and Technology Directorate, Cyber Security Division Homeland Security Advanced Research Projects Agency http://www.dhs.gov/topic/backend-attribute-exchange-secure-informationsharing DHS S&T Identity Management Testbed The Johns Hopkins University Applied Physics Laboratory RESTRICTION ON DISCLOSURE AND USE OF DATA. This document includes data that may be proprietary, may be legally privileged, and is for the intended recipient only. Access, disclosure, copying, distribution, or reliance on any of it by anyone else is prohibited and may be a criminal offense. If obtained in error, please delete. The data subject to this restriction is contained on pages marked: Use or disclosure of data contained on this page is subject to the restriction on the title page of this whitepaper.
Executive Summary: The ID DataWeb (IDW) Attribute Exchange Network (AXN) is an Internet-scale, neutral transaction services and contractual hub for enabling online credential authentication and attribute exchange services. The IDW AXN enforces privacy and security precepts driven by industry and in support of the National Strategy for Trusted Identities in Cyberspace (NSTIC) Guiding Principles. The exchange allows Identity Providers (IdPs), Attribute Providers (APs), Relying Parties (RPs), and users to federate and reuse credentials and attributes in a policy-driven, low-risk manner, at an affordable cost. AXN participants must register the contracting entity (e.g., corporation, agency, etc.) and each service (e.g., AP, IdP, or RP Web site, Web service, application programming interface (API), Lightweight Directory Access Protocol (LDAP) directory, meta-directory, etc.). Policy is applied at the service level through settings in the corresponding Admin Console on the exchange. The Department of Homeland Security (DHS) Science and Technology (S&T) Directorate established the Identity Management (IdM) testbed hosted at The Johns Hopkins University Applied Physics Laboratory (JHU/APL). The IdM testbed team has been tasked by S&T to identify solutions to capability gaps in identity and access management for the Homeland Security Enterprise, which includes Federal, State, and local governments, and the public and private sectors. The S&T IdM team partnered with the U.S. Department of Defense (DoD) Manpower Data Center (DMDC) to collaborate on a proof-of-concept implementation of the Backend Attribute Exchange (BAE) Security Assertion Markup Language (SAML) 2.0 Profile (BAE-Profile) in 2008. The BAE-Profile was developed to specify how a user who has been issued a credential is represented as a SAML subject, how an assertion regarding the user is produced and consumed, and finally how two entities exchange attributes about the user in a federated environment. The BAE-Profile has been transitioned and accepted for government-wide adoption by the Federal Identity, Credential, and Access Management (FICAM) Subcommittee (ICAM-SC) under the Federal Chief Information Officer (CIO), and can be found on IdManagement.gov. In addition, S&T is working with the Financial Services Sector Coordinating Council (FSSCC) on a project focused on reducing the risks of identity fraud and theft. The IdM testbed team developed the Verification of Identity Credential Service gateway to verify the validity of government-issued credentials, such as drivers licenses, social security numbers, and passports, to improve the identity proofing process of consumers opening financial accounts. As part of this effort, the IdM testbed team developed the extensible Access Control Markup Language (XACML) 3.0 Subject Data Verification Profile (XACML- Assertion-Profile), which describes translation, routing, and matching capabilities and defines the transaction between the RP and a gateway for validating a user s self-asserted attribute information. The AXN can support these protocols and requirements by integration with existing government BAE implementations and/or by direct registration of RPs and APs that require Authoritative Attribute (AA) and verification services. In all cases, the AXN requires the user to be present during the IDW AXN attribute exchange process and must always authorize the Back-Channel verification of attribute assertions. This approach actively engages the user in the attribute exchange process, thereby preserving user privacy and enabling active user management of RP interactions. Having the user opt in and assert their attributes promotes transaction trust and improves the quality and refresh of related transaction data. Overview The Identity Ecosystem has evolved to where each RP is required to establish its own transaction process with each IdP and AP. The IDW AXN solution is an Internet-scale transaction services hub and contractual hub for federating online credential authentication and Figure 1: AXN: A Transaction and Contractual Services Hub 2
attribute exchange services. The exchange allows IdPs, APs, RPs, and users to exchange and reuse credentials and attributes in a policy-driven, low-risk manner, and at an affordable cost. The AXN is built on open industry standards as a neutral transaction and claims management hub that can enforce privacy and security precepts driven by industry and in support of the NSTIC Guiding Principles. The AXN does not issue end-user credentials nor does it perform authentication or authorization, but it does enable these transaction services for participating IdPs (authentication) and RPs (authorization). RPs registered on the AXN can obtain credential authentication services available from FICAM-approved IdPs [for Level of Assurance (LOA) 1 to 4 using SAML 2.0, OpenID Connect, or OAuth 2.0] and user attribute verification services available from commercial APs [e.g., Experian, LexisNexis, Equifax, Verizon, AT&T, American Association of Motor Vehicle Administrators (AAMVA), etc.]. In addition, RPs can obtain verified user-asserted identity attributes and authoritative role-based attributes (from registered commercial and government AA sources) to support the following: Authentication credential tamper detection Attribute-based access control (ABAC) and management Provisioning (in advance) Personnel medical emergencies Enhanced response capabilities (e.g., first responder) The BAE-Profile details an implementation that an RP can use to obtain attribute information for a specific user through a direct or brokered connection to an AA service. Technically, the BAE-Profile defines a Simple Object Access Protocol (SOAP)-based SAML 2.0 attribute assertion implementation and can be used wherever that protocol and token apply. Operationally, the BAE-Profile (Figure 2) defines the Federal AA service required for delivering attribute content to Federal, State, or local government RPs. In practice, these government agencies are highly motivated to protect privacy and handle citizen information as extremely sensitive. The release of any citizen information even to other government agencies is scrutinized and highly regulated. In practice, governments do not release citizen information to non-government entities given the potential risk for unauthorized use. However, government AAs can provide limited support for data-matching requests from non-government clients when the citizen has self-asserted and approved the submitted data and Boolean predicate matching algorithms are embedded in the matching capability trusted by the AA service provider. In this configuration, the matching request and matching response support multiple pairs of data identifiers and values; namely, the self-asserted data Figure 2: Verifying Identity Credentials Service verification request and Boolean verification results. There are matching services provided by organizations that may centralize an aggregation of these government data verification services and shield these AA providers from direct exposure to the RP, e.g., AAMVA. The XACML-Assertion-Profile describes the intermediate actors and defines the transaction between the RP and the gateway. The BAE-Profile could participate on the AXN in two different scenarios: 1. Existing government BAE Brokers and Metadata Services could be integrated into the AXN as an AP service with defined policies for interoperability, authentication, and permissible use. Government RPs would register on the AXN and specify policies for which user attributes would need to be verified via participating APs, including these government-to-government-only providers. As such, existing government BAE Brokers and Metadata Services could be protected 3
from exposure through an XACML-Assertion-Profile gateway. This approach would minimize AXN integration requirements into existing BAE implementations. 2. New AP services could register directly on the AXN as they become available and publish their attribute service offerings along with restrictions for permissible uses and RP participation. The AXN provides online RP and AP registration and account management along with account support for charge back, usage, and central billing if these are desired features. The AXN AP gateway would enable all transaction processes and engage the user in transaction flows in support of NSTIC privacy policy. In addition, the AXN would not store attribute data or create a centralize data store. In either scenario, participating RPs register with the AXN. As defined by AP policies (e.g., white list and/or permissible use restrictions), each RP selects attributes, data types (authoritative, derived, selfasserted), and sources published by APs willing to verify and offer user-asserted attribute data. A set of verified user-asserted attributes and claims can readily be re-verified by APs and, with user consent, shared with participating RPs on demand. AXN Overview AXN transaction services between participants (i.e., RPs, IdPs, and APs) are standardized to a few specific models. Once each participant registers (see Figure 3) and completes integration with the AXN, no further work is required from an IdP or AP as the number of RPs grows on the exchange. Based on the RP registration settings, the AXN serves as a policy control point for credential and attribute information transactions, and only sends the required information to the RP, regardless of what was proffered by an IdP or AP. AXN participants must register the contracting entity (e.g., corporation, agency, etc.) and each service (e.g., AP, IdP, or RP Web site, Web service, API, LDAP directory, meta-directory, etc.). Policy is applied at the service level via settings in the corresponding Admin Console on the exchange. During AXN registration, an RP selects attributes to be verified using the minimal necessary data for the RP to authorize service and, as needed, perform account creation or binding of a credential to an existing account. The decision about what is required by an RP to authorize user access to an RP service or to create/bind a user account is based on corresponding Trust Framework policy, the RP s risk mitigation requirements, and any overarching privacy regime under which the RP operates (e.g., FICAM, Figure 3: AXN Registration and Management Services Gramm-Leach-Bliley Act, Health Insurance Portability and Accountability Act, etc.). The role of the AXN is to enable the management and enforcement of AP and RP policies and service requirements as defined in the corresponding (IdP, AP, and RP) Management Console on the AXN. The IDW AXN architecture enhances user privacy and control over verified user attributes without creating a centralized data store of user attributes at the AXN. The individual user s Personally 4
Identifiable Information is not stored at the AXN, but will be under direct user control via the user s Personal Data Service (PDS) at an online location of the user s choice. Users will assert their attributes at RP sites via the AXN to procure services and, as needed, to establish an RP account. After completing the first verification flow, users can leverage verified attributes from their PDS to access additional RP services and establish new accounts. This feature minimizes user friction and promotes user adoption. Throughout the identity ecosystem, users will leverage a credential issued and managed by their IdPs to enable single sign-on and to minimize password use. This reduces the administrative burden associated with account creation and maintenance while greatly improving the user experience. An AXN administrative operations team manages the process of registering and activating AXN subscribers. A subscriber could be an IdP, AP, or RP. Users will consume AXN services but will not subscribe to the AXN. Although most of the AP, IdP, and RP registration processes are fully Web-enabled and automated, the IDW AXN administrative operations team is required to perform a number of manual contractual audits and quality checks before releasing a subscriber into production. The list of attributes for the user to self-assert is determined at the time of RP registration on the AXN. In all cases, the AXN gathers user attributes (based on the RP registration requirements), verifies those attributes with participating AP services (again, based on RP registration requirements), and with user permission shares the user-asserted attributes and resulting AP claims with the RP. To resolve situations in which IdPs and APs prefer more user information than required, the AXN only verifies attributes asserted by users based on requirements established by the RP during registration. In this process, the AXN ignores any additional attributes that may be available from an IdP or AP interface, and only verifies the assertion claim for the self-asserted user information. As such, the AXN enables privacy policy enforcement and serves as audit compliance point for data minimization policies. Attribute-Based Access Control (ABAC) Services RPs that subscribe to this service can designate authoritative role-based attributes for users to assert when accessing their RP service to enhance detection of Authentication Credential tampering, access control and management, and user access and response capabilities (e.g., online and physical first responder access to a community RP service in a disaster zone). The AXN will also support dynamic, contextual, policy-driven mechanisms that allow RPs to make real-time decisions within a flexible framework to enforce real-time policy decisions. This requires decision-making capabilities to be external to systems, applications, or services, with input to these decisions based on information about the user, resource, and contextual information that may be expressed as attributes. These attributes can reside at multiple AP sources where the level of confidence in an RP attribute may vary. The AXN uses a unique method to supply attributes at the time of the Authentication Assertion. There is a one-time use key for the RP to retrieve the attributes associated with the assertion in the encrypted token that includes session details and the Authentication Assertion. The expectation is the RP service will immediately retrieve these attributes to support the RP service Authorization decision. The AXN does not use the RP s session to pass data about the user. The AXN requires the RP service to use the one-time use token to retrieve the data via an asynchronous session using the defined scheme for the RP. Additional elements that could be included in the retrieval token are: (1) any customer asserted attributes and (2) any collected attribute verification data. This process of separating the transmission of the Authentication Assertion and the customer data using a second asynchronous session increases the security and reduces the impact of a man in the middle attack. The AXN can verify attributes used in the IdP Credential (Authentication Assertion) authentication process and passed to the AXN by the IdP. This is accomplished by asking users to opt in to having their attributes verified after being authenticated by the IdP and before they are returned to the session on the RP. We recommend this process happen a minimum of once per year, but it can occur more often based on the RP service risk profile requirements. The verification process leverages the data packet (SAML or OpenID) from the IdP and verifies the data using a third-party attribute provider (e.g., Experian). Trust 5
Framework Provider Policies generally dictate the implementation options for RP services. Attribute verification options include: (1) self-asserted attributes, (2) prefill attributes from a masked version of the attributes received from the IdP, and/or (3) the request of attributes outside the SAML/OpenID Scheme. Attributes are encrypted and staged for the RP service to retrieve from the AXN along with the claims (Pass/Fail) associated with the attributes assertions. Summary The IDW AXN is an Internet-scale, neutral transaction services and contractual hub for online exchange of credentials and attributes that can enforce privacy and security precepts driven by industry and in support of the NSTIC Guiding Principles. The exchange allows IdPs, APs, RPs, and users to federate and reuse credentials and attributes in a policy-driven, low-risk manner and at an affordable cost. AXN participants must register the contracting entity (e.g., corporation, agency, etc.) and each service (e.g., AP, IdP, or RP Web site, Web service, API, LDAP directory, meta-directory, etc.). Policy is applied at the service level via settings in the corresponding Admin Console on the exchange. The AXN can support these protocols and requirements by integration with existing government BAE implementations and/or by direct registration of RPs and APs that require AA and verification services. In all cases, the AXN requires users to be present during the IDW AXN attribute exchange process and must always authorize the Back-Channel verification of attribute assertions. This approach actively engages users in the process, thereby preserving customer privacy and enabling active user management of RP interactions. Having users opt in and assert their attributes promotes transaction trust and improves the quality and refresh of related transaction data. 6