Preview: Anil John
Anil John | BlogOn Architecture, Digital Security, Service Orientation...Updated: 2012-01-30T18:40:30.327-05:00
Privacy Preserving Attribute Verification using XACML 2011-12-30T15:40:28.695-05:00 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: A person needs to complete a transaction with a (commercial) entity (Obtain a high assurance credential, Open an account etc.) Person self-asserts a set of claims/attributes; this may be via documents or electronic; in person or remote 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 po[...]
User Consent in the Age of Attributes 2011-11-13T22:21:08.496-05:00 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. These 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. This work is licensed under a Creative Commons 3.0 License. [...]
Reality of XACML PEP-PDP Interoperability - Part III 2011-10-30T12:36:18.752-04:00 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: Using the standard
Standards Compliance: Balancing Purity and Pragmatism 2011-10-24T08:11:44.253-04:00 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. These 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. This work is licensed under a Creative Commons 3.0 License. [...]
Implications of US Gov Accepting Externally-Issued Credentials 2011-10-16T14:35:06.649-04:00 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 be[...]
US Gov public web sites required to accept federated credentials 2011-10-15T17:12:25.641-04:00 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 These 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. This work is licensed under a Creative Commons 3.0 License. [...]
User Attributes - More than Identity 2011-10-08T13:20:32.759-04:00 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! These 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. This work is licensed under a Creative Commons 3.0 License. [...]
HOW-TO: Conduct a Risk Assessment to Determine Acceptable Credentials 2011-10-02T13:54:28.450-04:00 As I mentioned in my earlier HOW-TO on "Fast Track to Federation for Web Sites", the first step in that process is to conduct a web site risk assessment and use the results to determine the type and strength of credentials you will accept at your web site. The risk assessment provides a mechanism to evaluate each web site using a consistent criteria, and provides a contextually driven mechanism that balances the need for protection of the information with the responsibility to share that information with the appropriate audience. While this process is equally applicable to internally facing web sites, it is absolutely critical for externally facing web sites that need to accept federated credentials. The combination of "E-Authentication Guidance for Federal Agencies (OMB-M04-04) [PDF]" and "FIPS 199 Risk/Impact Profiles [PDF]" are the mechanisms used by the US Government in assessing its own web sites, and have become one of the most widely used mechanisms for how to conduct a web site risk assessment. Yet, many people are either not aware of this excellent (and free) resource or discount it as being too "heavy-weight". I hope to, in this blog post, provide an overview of this process and show you through a worked example how it is possible to apply it very easily in the majority of cases. Risk from authentication error is a function of two factors: (a) potential harm or impact and (b) the likelihood of such harm or impact. The categories of harm and impact as well the three potential impact values (Low, Moderate or High) are given below: Inconvenience, distress or damage to standing or reputation (Low/Moderate/High) Financial loss or organization liability (Low/Moderate/High) Harm to an organization's programs or public interests (Low/Moderate/High) Unauthorized release of sensitive information (Low/Moderate/High) Personal safety (Low/Moderate-High) Civil or criminal violations (Low/Moderate/High) Given below is an example of the evaluation criteria applied to a web site that has resulted in specific and contextual choices by the evaluator (Please follow the category links above to see definitions of what Low, Moderate and High mean). Note that there exists sensitive information on the web site, that if released improperly, could have a "Low" impact on the organization (i.e ... cause a degradation in mission capability to an extent and duration that the organization is able to perform its primary functions, but the effectiveness of the functions is noticeably reduced) As such, due to the low impact of unauthorized release of sensitive information due to an authentication error, a credential issued in a manner that provides a Level of Assurance (LOA) 2 (i.e. "Some confidence in the asserted identity's validity)" is needed at a minimum. Risk Analysis - Worked Example Once the minimum needed LOA has been determined, it is straight forward to map that to the type of credentials that can support the needed LOA using the "NIST Electronic Authentication Guideline (SP 800-63) [PDF]". But I will emphasize a specific point that is often glossed over or de-emphasized when it comes to this mapping. The term "assurance" has a specific meaning here and is defined as the degree of confidence in the vetting process used to establish the identity of the individual to whom the credential was issued (i.e. the identity proofing component) and the degree of confidence that the individual who uses the credential is the individual to whom the credential was issued (i.e. the "technical strength" of the credential itself) The combination of both factors determine the particular credential type that can support a specific LOA, as shown in the table below. Related Posts: HOW-TO: Fast Track to Federation for Web Sites How do you define step up authentication? These are solely my[...]
How do you define step up authentication? 2011-09-21T20:47:42.475-04:00 I was in a meeting today discussing some user scenarios and "Step Up Authentication" came up as a particular scenario we needed to address. But there was a disconnect in how the term was being used that led to confusion. The two usages were:
Which of the above scenarios comes under the heading of "Step Up Authentication"?
I believe that option (1) is what is meant by the term Step Up Authentication. I look at option (2) as the application of compensating controls. I would be interested in hearing if there is general consensus one way or the other around the term Step Up Authentication.
HOW-TO: Fast Track to Federation for Web Sites 2011-10-02T13:32:06.042-04:00 I was recently asked what steps I would take to implement the capability to accept Federated Credentials at a web site. Since that is a question I have been asked before, I figured I would document it here for future reference. While the answer is equally applicable to the commercial sector, given that the majority of the work I do is in the US Government space, I am answering this question as if it were being asked of me by a Government Program Manager who wants to begin accepting Federated Credentials at his web site. Needless to say, this is my personal opinion. At a high level, these are the steps: Conduct a web site risk assessment to determine the Level of Assurance (LOA) needs of the web site. Use OMB-O4-O4 [PDF] and FIPS 199 Risk Impact Profiles [PDF]. Determine what credential technology strength can support the required LOA. Use NIST SP 800-63 [PDF] Determine the target audience for the web site and see what credential providers they have available to them (e.g. OpenID 2.0 IdP, SAML 2.0 IdP, PIV/PIV-I Cards etc.) Down-select the available credential providers to those who support the required LOA. Use the list of FICAM Trust Framework Provider (TFP) IdPs on IDManagement.gov. Use Credential Providers who use Protocol Profiles (of OpenID 2.0, SAML 2.0 etc.) that address Security and Privacy concerns at the needed LOA. Down-select to list of FICAM TFP Certified Credential Providers on IDManagement.gov that support FICAM Protocol Profiles at the required LOA. Implement support for protocol profiles at the web site using COTS, Open Source and/or custom development. Use product vendors and/or code that support the selected FICAM Protocol Profiles at the needed LOA. (NOTE: I don't have a link to provide for you at this time, but I am aware of multiple COTS vendors who currently have support for various FICAM protocol profiles or have committed to support them in their product for release in the near future. Hopefully there will be a Government web site that provides that information soon.) Comments, questions and suggestions for improvement are very welcome. Related Posts: HOW-TO: Conduct a Risk Assessment to Determine Acceptable Credentials These 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. This work is licensed under a Creative Commons 3.0 License. [...]
nymwars and All your real names are belong to US 2011-09-11T18:13:28.276-04:00 I've been following the nymwars with interest from both a personal and professional perspective. Check out the following to gain an appreciation of the ongoing conversation: http://www.scoop.it/t/plusgate http://my.nameis.me/ Google+ Can Be A Social Network Or The Name Police – Not Both Google+ and The Trouble With Tribbles http://www.identitywoman.net/ In recent days, I have been amused to note that there has been an attempt in some quarters to link the Google+ policy around real names to US Government initiatives such as the National Strategy for Trusted Identities in Cyberspace (NSTIC) program and/or the Federal Identity, Credential and Access Management (FICAM) program (which among other aspects is the US Government's internal implementation of the NSTIC vision). Thought I would take a quick moment to point out support for anonymity and pseudonyms in both those programs. NSTIC "[...] will protect individuals’ capacity to engage anonymously in cyberspace. Universal adoption of the FIPPs in the envisioned Identity Ecosystem will enable a variety of transactions, including anonymous, anonymous with validated attributes, pseudonymous, and uniquely identified—while providing robust privacy protections that promote usability and trust" FICAM To understand the techno-speak, know that a credential that you have (i.e. a userid/password, one-time-password key-fob, smart card, etc) can be assigned an "assurance" level on a scale of 1 to 4. This is based on (1) the degree of confidence in the vetting process used to establish the identity of the individual to whom the credential was issued, and (2) the degree of confidence that the individual who uses the credential is the individual to whom the credential was issued. This number is known as the Level of Assurance (LOA) of the credential. For Level of Assurance (LOA) 1 credentials (userid/passwords, OpenID etc.), there is no requirement to use a real name. For Level of Assurance (LOA) 2 credentials there is explicit support for pseudonyms: "The name associated with the Subscriber may be pseudonymous but the RA or Identity Provider shall know the actual identity of the Subscriber." BTW, I really am not expecting to change opinions using facts, but thought I would throw the pointers out there for folks who do want to fact-check on their own. These 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. This work is licensed under a Creative Commons 3.0 License. [...]
FICAM Trust Framework Provider Trust and Privacy Criteria 2011-09-12T08:47:59.993-04:00 The Federal ICAM Trust Framework Provider Trust Criteria [PDF] and associated Privacy Guidelines [PDF] have been out there for a while, but given that it exists only in PDF form, it does not seem to have much visibility. I finally got frustrated with the inability to send a link to someone with a quick reference, and tired of having to break out the PDF any time I wanted to look something up. So I decided to convert the relevant portions of both documents into a linkable HTML format. Hope that folks find it useful. What are Levels of Assurance (LOA)? FICAM Trust Criteria for Level of Assurance (LOA) 1 Registration and Issuance Tokens Token and Credential Management Authentication Process Assertions FICAM Trust Criteria for Level of Assurance (LOA) 2 Registration and Issuance Tokens Token and Credential Management Authentication Process Assertions FICAM Trust Criteria for Level of Assurance (LOA) 3 Registration and Issuance Tokens Token and Credential Management Authentication Process Assertions FICAM Trust Criteria for Level of Assurance (LOA) 4 FICAM Privacy Guidance for Trust Framework Assessors and Auditors Adequate Notice Opt-In Minimalism Activity Tracking Non Compulsory Termination Identity Provider Bona Fides These 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. This work is licensed under a Creative Commons 3.0 License. [...]
Comparing BAE v2 SAML Profile(s) and OASIS XASP 2011-08-31T22:13:39.842-04:00 Now that the FICAM Backend Attribute Exchange (BAE) v2 specifications have reached RC status and are available for public review, one of the questions that is sometimes asked is for a comparison between the BAE v2 SAML Profile(s) (Identifier and Protocol Profile and Metadata Profile), and the OASIS X.509 Attribute Sharing Profile (sometimes called XASP). BAE Profile of SAML 2 OASIS XASP (Encrypted Mode) Supported NameID Format(s) urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName urn:idmanagement.gov:icam:bae:v2: SAML:2.0:nameid-format:fasc-n urn:idmanagement.gov:icam:bae:v2: SAML:2.0:nameid-format:uuid (Communities may define their own) urn:oasis:names:tc:SAML:1.1:nameid-format:x509SubjectName SSL/TLS MUST - Over an SSL Channel MAY - Use SSL/TLS Client Authentication MUST – Over an SSL Channel MAY - Use SSL/TLS Client Authentication Digital Signature MUST - samlp:AttributeQuery MUST - saml:Assertion MUST - soap:Body MUST - samlp:AttributeQuery MUST - saml:Assertion MUST - samlp:Response Encryption MAY - saml:NameID [Per Metadata] MUST - saml:Assertion MUST - saml:NameID MUST - saml:Assertion EntityID, Issuer, Destination MUST - Naming convention based on NIST SP800-87 Agency Codes for PIV, AKI and Org Name for PIV-I and Community defined for other credential types ? Metadata MUST - Per Profile MAY - ? Trust Anchor CA MUST – EGTS CA (for issuance of Signing and Encryption certificates in the FICAM environment). May use own CA within a community. ? There are some additional differences in the Attribute Exchange Design patterns that are supported by the two profiles (See Sections 3 & 4 of the BAE v2 Overview for more information). These 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. This work is licensed under a Creative Commons 3.0 License. [...]
FICAM Backend Attribute Exchange v2 Release Candidate available 2011-08-27T15:11:42.097-04:00 The Federal ICAM Backend Attribute Exchange (BAE) v2 specifications have reached release candidate status, and are now available on IDManagement.gov (See below for direct links to the specification). The FICAM BAE v2 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. The BAE v2 specification set consists of: BAE v2 Overview[http://www.idmanagement.gov/documents/BAE_V2_Overview.pdf] Federal ICAM Governance for BAE v2[http://www.idmanagement.gov/documents/BAE_V2_Governance.pdf] SAML 2.0 Identifier and Protocol Profiles for BAE v2[http://www.idmanagement.gov/documents/SAML_V2_IP_Profiles.pdf] SAML 2.0 Metadata Profile for BAE v2[http://www.idmanagement.gov/documents/SAML_V2_Metadata_Profile.pdf] SPML 2.0 Read-Only Profile for BAE v2[Currently being developed and tested via a pilot] NOTES: BAE v2 allows you to implement a "Pull Based" Identity and Access Control Architecture We deliberately made sure that the "SAML 2.0 Identifier and Protocol Profiles, and the SAML 2.0 Metadata Profile" for BAE v2 can stand on their own and has no dependencies on the FICAM and/or Government Agency Governance processes. This allows any organization (commercial or otherwise) to implement a pull based identity architecture using a standards based and tested approach. Multiple COTS vendors have already baked in support for the BAE v2 technical profiles into their products. User guides for how specific products can be configured to support BAE v2 are currently being developed and will be available shortly. An implementation of BAE v2 has been deployed in the DHS S&T IdM Testbed for a while now, which has been used for T&E, pilots, as well as interoperability testing with vendor implementations. Recently, as part of an MOU between FICAM and DHS S&T, this implementation has been designated as the FICAM Reference Implementation for BAE v2. DHS S&T IdM Testbed, in partnership with the FICAM Lab (which will manage the test metadata) will be working to support the enablement of the BAE environment for use by US Federal Government departments/agencies and others. These 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. This work is licensed under a Creative Commons 3.0 License. [...]
Summer in the Shenandoah National Park 2011-07-04T15:33:10.980-04:00 The U.S. National Park System is one of the truly great treasures that can be enjoyed by all generations of people that live and visit the United States. On the East Coast of the United States, one of the crown jewels of the National Park System is the Shenandoah National Park. For those who are interested in visiting the Shenandoah National Park, I would recommend the following two resources as starting points: http://www.visitshenandoah.com/ http://www.nps.gov/shen/index.htm As someone who enjoys hiking and backpacking, I am extremely fortunate that we live within a 3 hour ride of the Shenandoah National Park, which has over 500 miles of trails, including 101 miles of the Appalachian Trail. My family and I spent this long Independence Day weekend in the Park and had a very relaxing and enjoyable time. While there are many lodging options, we chose to stay at the Skyland Lodge which, at mile 41.7 of the Skyline Drive, is centrally located and provided a great base to explore all that the Park has to offer. As mentioned on their web site "If you are looking for 4 diamond, luxury accommodations with all the amenities, Skyland is not the place for you. The absence of in-room phones and WIFI only enhances the quietness of the surroundings. Skyland lets you leave the hi-tech world behind so you can immerse yourself in the tranquility of nature." Given that the opportunity to disconnect completely and enjoy the surroundings together was exactly what we were looking for, this worked out very well for us. On a related note, given my son's multiple food allergies, a criteria that we use to gauge whether or not we will ever stay at a place again is how they address our concerns with food allergies. And on that score, ARAMARK, which manages and operates the concessions in the Shenandoah National Park and operates it under contract to the National Park Service, turned out to be absolutely top notch and we could not have been happier with them. I especially want to call out and complement Mr. Peter Bizon, the Executive Chef for the Park's ARAMARK managed properties (which includes Skyland), who personally coordinated the service that we received from the restaurant and from all the food service staff. He and his staff were friendly, accommodating, and made my son feel special and not different, and we can’t ask for anything more than that. Thank You, Peter! We did some hiking around the area, which included a bit of the Appalachian Trail, and discovered that the Skyland area is very near the highest point of the Appalachian Trail within the Shenandoah National Park. All in all, we had a great time and a visit to a National Park, and especially Shenandoah if you are on the East Coast, is something I would highly recommend to take a refreshing break from our our furious, fast paced, always connected world.These 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. This work is licensed under a Creative Commons 3.0 License. [...]
Converging Logical and Physical Access Control via XACML 2011-06-19T12:52:49.977-04:00 The desire to externalize authorization and to drive access control via standardized policy has been one of the major contributors to the success of XACML. Typically, this has been focused almost exclusively on Logical Access Control Systems (LACS). But, what if you could define and manage your access control policies for both Logical Access Control Systems (LACS) and Physical Access Control Systems (PACS) from a single pane of glass? Over the last number of years, in my role as the Technical Lead for DHS S&T's IdM Testbed, I've been working with companies that participate in the DHS Science & Technology Directorate's Small Business Innovation Research (SBIR) Program. One of the interesting projects that I've provided technical advice and guidance to has been with an SBIR Awardee (Queralt, Inc) that has developed a PACS Policy Enforcement Point (PEP) that conforms to the XACML 2.0 and 3.0 standard. Moving out on this, we fully realized that the perspectives of the physical security folks are often different than the IT folks who typically run LACS systems. As such it is important to make sure those concerns are addressed up front. Those concerns include: The access control policies for the PACS system must remain under the control of the physical security officers The PACS system must continue to operate even if this additional functionality is disabled for some reason This is an additional functionality built on top of existing capabilities and must easily integrate with existing infrastructure As an aside, when we speak of Attribute Based Access Control (ABAC), the input to a decision includes identity attributes, authority attributes, actions to be performed and environmental attributes as well. One of those environmental attributes could be location information. The key with location information is that in order for it to be relevant, it must come from a trusted infrastructure i.e. I can easily trust location information from a turnstile that is owned and managed by my organization but I would have a harder time trusting location information from a computer or mobile device coming from a wireless network that can more easily be spoofed. This capability allows for the incorporation of location information from a trusted infrastructure. As always, a completely standards based interface between the PACS PEP and a PDP is critical to the success and adoption of this type of technology. As such Queralt is currently in the process of finishing up testing against the multiple XACML PDPs we have made available to them from our Testbed. So far everything looks good. We have also connected them with multiple leading XACML PDP vendors, who are very interested in this technology that will help them expand their reach into the PACS realm. Queralt, which has a focus on location based technologies and RFID, already has excellent relationships with multiple PACS vendors as well. All in all, to paraphrase a physical security officer who received a briefing on this effort last week, this is a game changer that many folks have been looking for and really need. Just as a disclaimer, other than my involvement noted above, I personally have no vested interest in Queralt as a company. I do think that this is very cool tech and it is something that will add greater value to policy driven access control decisioning capabilities. As such, if you are a PDP or PACS vendor and would like to be connected to the folks at Queralt, please do drop me a line and I would be glad to make that happen. These are solely my opinions and do not represent the thoughts, inten[...]
Update on Federal ICAM Profiles for Backend Attribute Exchange (BAE) v2 2011-06-18T21:43:52.096-04:00 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 [...]
Canvas Theory of Identity LOA vs Canvas Theory of Access Control 2011-06-13T10:47:30.266-04:00 In the many conversations that took place in the sidebars, asides and hallways of the NSTIC Governance workshop this past Thursday and Friday, I found one, which I am calling the "Canvas Theory of Levels of Assurance (LOA)", to be particularly interesting. It goes something like this: The current definition of Identity LOA, as defined by OMB and NIST [1], are too rigid/inflexible/yesterday/not today/[insert your preferred word here]. A model that is more [insert your opposing word choice here] is to treat a credential as a blank canvas. Over time, as the credential is used in transactions, the image of the credential holder becomes more and more clear on the canvas. And based on this visibility, the LOA of the credential can increase as more becomes known about the credential holder and their behavior. Alternatively it can also move down if the behavior or details about them are not in synch. As such LOA is something that should be dynamic, flexible and capable of real-time changes. As a first step, it is important to be very clear about what LOA means. Paraphrasing OMB M-04-04 [2], [an] assurance level describes the [Relying Party's] degree of certainty that the user has presented an identifier (a credential in this context) that refers to his or her identity. In this context, assurance is defined as (1) the degree of confidence in the vetting process used to establish the identity of the individual to whom the credential was issued, and (2) the degree of confidence that the individual who uses the credential is the individual to whom the credential was issued. What is important to note here is that the Relying Party's degree of certainty is dependent on both the process used to establish the identity of the person before the credential is issued to them, and the confidence that the credential is indeed being used by the person to whom it has been issued. Secondly, if the end result is the subject being granted (or denied) access to information stored at a web site or the ability to invoke a service to perform some actions on their behalf, the implementation of the vision above results in the following: The "canvas attributes" (for lack of a better word) are not used as part of the access control decision but is instead used to "tune" the LOA level up or down The access control decision is then made primarily based on the new "tuned" LOA level The "tuned" LOA level has no connection to the vetting process and is simply dependent of the consistency and "knowledge-over-time" behavior of the credential Potentially frustrating experience for the subject because the relying party, since it has little or no confidence in the asserted identity's validity, may not be able to give the subject access to the information up front Even more critically important, the risk of identification of the subject now resides solely with the relying party Whenever something like this is proposed, it is always worthwhile to look at who benefits from such a model. This is a model in which the IdP has no responsibility to put in place a vetting process to establish the identity of the subject, and has no liability when it comes to the potential mis-identification of the subject. Needless to say, the entities that I see this model appealing to are large consumer IdPs who do not want to disturb their existing identity proofing processes (or lack thereof) that they have with their customers. This approach ultimately does not move the ball forward towards an identity eco-system that allows one to conduct high value and/or privacy sensitive medical, financial and government transactions. [...]
Identity Oracles - Trust is Ephemeral, Contracts are Eternal 2011-06-05T15:17:48.115-04:00 In many conversations I have had with folks who potentially have a need for the services of an Identity Oracle, especially as to how it could help with assurances of identity, there is a two part reaction that I found to be very interesting as indicators of what we need to focus on as a community to make this real and viable. The first part of the reaction is typically about the “many security holes” in the concept and “changes to existing business processes” that are needed to leverage the capability. The second part of the reaction takes place a bit later as we get into discussing identity proofing and bring up the example of US Government PIV cards (which are Smart Cards that are issued to US Government Employees and Contractors) or Non Federally Issued PIV-I Cards, both of which have have transparent, publically documented, and consistent identity proofing process and the level of comfort the same set of folks have in potentially changing their business processes to accept the PIV/PIV-I Card as a proxy for identity proofing that has been done by someone else. What that combination of reactions confirmed for me is that the issue is not about technology/security holes (since the the Identity Oracle is a business and NOT a technology) or about changing business practices (since the second part requires that change as well) but about the level of comfort and confidence one can place in the relationships between the Identity Oracle and entities that need to interact with it. I prefer to not use the word “Trust” in this context because the definition is ambiguous at best (See Gunnar Peterson’s “Lets Stop ‘Building Naïveté In’ - Wishing You a Less Trustful 2011” blog post) but instead would like to focus on the contractual aspects of what can be articulated, measured and enforced as both Gunnar in his blog and Scott David in my earlier “Identity Oracles – A Business and Law Perspective” blog post noted. This tension between the technical and the business also came up in the reactions (@independentid, @NishantK, @IDinTheCloud, @mgd) to my original post on Identity Oracles, so would like to explicitly address that in this post. How does the traditional “pure tech” Identity and/or Attribute Provider operate and what if any are the constraints placed upon it? From a technical interaction perspective, you have: Person presents to the Relying Party some token that has binds them to a unique identifier Relying party uses that unique identifier to call out to the Identity/Attribute Provider to retrieve attributes of the Person The Identity/Attribute Provider interacts with Authoritative Sources of information about the Person and returns the requested information to the Relying Party Now let us look at this from a non-technical interaction perspective: A contractual relationship exists between the Authoritative Sources and the Identity/Attribute Provider A contractual relationship exists between the Identity/Attribute Provider and the Relying Party A contractual relationship exists between the Person and the Relying Party NO contractual relationship exists between the Person and Identity/Attribute Provider Privacy Implications The Relying Party typically click-wraps its privacy and information release in its interactions with the Person The identity/attribute provider, as a business entity which needs to make money, is dependent on Relying Parties for its revenue stream The identity/attribute provider, as the entity in the middle, has visibility into the transactions that are conducted[...]
Identity Oracles – A Business and Law Perspective 2011-06-05T15:17:48.115-04:00 Reminder: The Identity Oracle idea is NOT mine, but I have become convinced that it, or something like it, needs to exist in a healthy Identity Eco-System. The concept is something that was originally proposed by Bob Blakley and expanded upon by him and others at Gartner/Burton Group. I am simply trying to gather the information that exists in a variety of places into one cohesive narrative, and adding my own perspective to move the conversation forward on this topic. One of the aspects of the Identity Oracle is that it is not a technology but a business that proposes to address the relationship between Subjects, Relying Parties and Authoritative Sources of Information via mechanisms such as Contract Law. I am not a lawyer and I do not play one on TV. So when I had questions about the viability of the Identity Oracle from a Law and Business perspective, I pinged Scott David at K&L Gates. Scott and I have ended up at a lot of the same identity focused events in recent months and I have really enjoyed conversing with him about the intersection of Identity, Privacy and Law. As someone who is passionate about those topics, and works in the domain, he brings a critical insight to this discussion. My request to Scott was to read my previous blog entry on Identity Oracles and answer if the concept was “… feasible or is it a Utopian vision that is a bridge too far?” The short version of the answer that I got was: “I agree with much of the strategy of what you suggest in the blog, but I have some comments on tactics” But because the long version of his answer is so very thought provoking, I am posting it here, with his permission. I do take some liberties below by commenting on Scott’s words and providing external links to some of his references. Here is Scott, in his own words: Anil – The following are my personal comments to your blog entry. They do not reflect the views of my firm (K&L Gates LLP) or any of its clients. I guess I would say you are "getting warmer," but there are some underlying assumptions on the legal side in the path that you outline that will likely prevent achieving internet scale through the path described. With some changes in assumptions and design and deployment tactics, however, the market-oriented system that you contemplate can, I think, be built to accommodate the needs of global data/identity systems. If we treat law as a technology (just as "language" is a "technology") in need of standardization, and look at law from a systems, information science, thermodynamics, AND economic incentives perspective, the following additional points quickly suggest themselves as requiring accommodation in internet scale systems. 1) You are right-on with emphasis on contract law. Massively interoperable systems require Rules standardization (not just technical standardization) on a broad scale. The most system relevant rules (the only one's on which system users can rely) will be those that are enforceable. Those are called legal duties. They arise two ways: by legislation (regulation or other government action) or contract. There is no single international legal jurisdiction (see Peace of Westphalia - 1648), so legislation and regulation alone cannot drive standardization. The international law is the law of contracts (minimum coverage of treaties aside). Standardized, enforceable, international contracts involving remote parties dealing in valuable intangibles/data are entered into literally every second . . .that activity takes place in the curren[...]
Identity Oracles and their role in the Identity Eco-System 2011-06-05T15:17:48.116-04:00 The concept of the Identity Oracle is something that I have been giving a lot of thought to recently. It has been driven by a combination of factors including current projects, maturity of both policy conversations and technology, as well as a desire to move the art of the possible forward at the intersection of identity and privacy. My intention is to use this blog post to provide pointers to past conversations on this topic in the community, and to use that as a foundation for furthering the conversation. When it comes to information about people (who they are, what they are allowed to do, what digital breadcrumbs they leave during their daily travels etc.), there exists in the eco-system both sources of information as well as entities that would find value in utilizing this information for a variety of purposes. What will be critical to the success of the identity eco-system is to define, as a starting point, the qualities and behavior of the "entity-that-needs-to-exist-in-the-middle" between these authoritative sources of information and consumers of such information. I believe the Identity Oracle to be a critical piece of that entity. So, what is an Identity Oracle? Bob Blakley, currently the Gartner Research VP for Identity and Privacy, coined the phrase "Identity Oracle", and provided a definition in a Burton Catalyst 2006 presentation: An organization which derives all of its profit from collection & use of your private information… And therefore treats your information as an asset… And therefore protects your information by answering questions (i.e. providing meta-identity information) based on your information without disclosing your information… Thus keeping both the Relying Party and you happy, while making money. That is as succinct a definition as I've seen in the many conversations on this topic since that time, and since I have no desire to re-invent the wheel, this is as good a starting point as any. The key point to note here is that this is NOT technology but a business, and as such if there is any hope for this to work, this business needs a viable business model i.e. something that makes it money. As Bob notes, some of the questions that need be answered by the current eco-system denizens such as Identity Providers, Attribute Providers and Relying Parties include: Paying for the Identity Provider server and the service it provides. Convincing Relying Parties that they should rely on information provided by a third party (the Identity Provider) rather than maintaining identity attribute information themselves. Assigning liability when a Relying Party asserts that a claimed identity attribute is incorrect. Assigning liability when a subject claims that the wrong identity attribute claim was released to a Relying Party. Making subjects whole when a security failure “leaks” subject identity attributes directly from the Identity Provider. Assigning liability and making subjects whole when a security failure “leaks” subject identity attributes from a Relying Party. I will add the following to the above list: Making subjects whole when the Identity/Attribute Provider's desire to monetize its visibility into the transactional information across multiple Relying Parties overrides its responsibility to protect the subject's personal information. As always, whenever something like this is proposed there is a tendency for technologists to try and map this to technology implementations. In this case technologies [...]
Want ABAC? Across Organizations? Start with Policy! 2011-06-05T15:12:47.269-04:00 Input to access control decisions are based on information about the subject, information about the resource, environmental/contextual information, and more, that are often expressed as attributes/claims. But how do you determine what those attributes/claims should be, especially as it relates to information about the subject? The typical way that I have seen folks handle this is based on a bottom up approach that gets a whole bunch of folks who manage and maintain directory services, lock them in a room and throw away the key until they can come to some type of agreement on a common set of attributes everyone can live with based on their knowledge of relying party applications. This often is not …ah… optimal. The other approach is to start at the organizational policy level and identify a concrete set of attributes that can fully support the enterprise’s policies. My team was tasked with looking at the latter approach on behalf of the DHS Science and Technology Directorate. The driving force behind it was coming up with a conceptual model that remains relevant not just within an Enterprise but also across them i.e. in a Federation. Couple of my team members, Tom Smith and Maria Vachino, led the effort which resulted in a formal peer-reviewed paper that they presented at the 2010 IEEE International Conference on Homeland Security [PPTX] last month. The actual paper is titled “Modeling the Federal User Identity, Credential, and Access Management (ICAM) decision space to facilitate secure information sharing” and can be found on IEEExplore. Abstract: Providing the right information to the right person at the right time is critical, especially for emergency response and law enforcement operations. Accomplishing this across sovereign organizations while keeping resources secure is a formidable task. What is needed is an access control solution that can break down information silos by securely enabling information sharing with non-provisioned users in a dynamic environment. Multiple government agencies, including the Department of Homeland Security (DHS) Science and Technology Directorate (S&T) are currently developing Attribute-Based Access Control (ABAC) solutions to do just that. ABAC supports cross-organizational information sharing by facilitating policy-based resource access control. The critical components of an ABAC solution are the governing organizational policies, attribute syntax and semantics, and authoritative sources. The policies define the business objectives and the authoritative sources provide critical attribute attestation, but syntactic and semantic agreement between the information exchange endpoints is the linchpin of attribute sharing. The Organization for the Advancement of Structured Information Standards (OASIS) Security Assertion Markup Language (SAML) standard provides federation partners with a viable attribute sharing syntax, but establishing semantic agreement is an impediment to ABAC efforts. This critical issue can be successfully addressed with conceptual modeling. S&T is sponsoring the following research and development effort to provide a concept model of the User Identity, Credential, and Access Management decision space for secure information sharing. The paper itself describes the conceptual model, but we have taken the work from the conceptual stage to the development of a logical model, which was then physically implemented using a Virtual Directory which acts as the backend for an Enterprise’s Au[...]
Federal ICAM Support for Identity Federation Flows 2011-10-08T21:59:05.753-04:00 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] When I think of the components of Identity Federation, I tend to bucket them into the 3 P’s; Protocol, Payload and Policy: ProtocolWhat 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 Brokered I (Federated) and Brokered II (Federated) flows are supported at LOA 1, 2 and Non-PKI 3 using the ICAM OpenID 2.0 Profile [PDF], ICAM IMI 1.0 Profile [PDF], Kantara eGov 1.5 Profile [PDF] and the ICAM SAML 2.0 Web Browser SSO Profile [PDF] Brokered II (Federated) flow is supported at LOA 3 and LOA 4 by usage of the Federal PKI Bridge with PKI infrastructures issuing PIV Cards for Federal Government entities and PIV-I Cards [PDF] for Non-Federal and Commercial entities Federal ICAM Support for Attribute Exposure Flows Organizational Query and Single Point of Query 1 flows are supported by the ICAM SAML 2.0 Web Browser SSO Profile [PDF] Organizational Query, Single Point of Query 1, Single Point of Query 2 and Identity Oracle flows are supported by the ICAM Backend Attribute Exchange (BAE)* Federal ICAM Support for Authorization Flows Front Channel Attribute Based Access Control (ABAC) flow is supported by the ICAM IMI 1.0 Profile [PDF] and the ICAM SAML 2.0 Web Browser SSO Profile [PDF] Back Channel ABAC flow is supported by ICAM Backend Attribute Exchange* (BAE) PayloadWhat 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) (v1) 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. PolicyThe 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[...]
Federation Flows 3 - Authorization 2011-06-05T15:18:28.627-04:00 After the blog posts on Authentication and Attribute Exposure options in the federation of identities, this post is going to focus on putting it all together for authorization. The caveats noted in the earlier posts apply here as well. Authorization – Front Channel Attribute Based Access Control Clear separation of security boundaries Clear separation between Authentication and Authorization Resource B needs attributes of Subject A to make access control decision Resource B accepts Subject A mediating attribute delivery from authoritative sources to Resource B 1) Subject A’s attributes are gathered as part of the cross-domain brokered authentication Flows Supports both Brokered I and Brokered II Authentication Flows Supports both Organizational Query and Single Point of Query 1 Attribute Exposure Flows 2) Subject A’s attributes are presented as part of one of the cross-domain brokered authentication flows 3) PDP B makes an access control decision based on attributes that have been gathered and presented While Broker A and Attribute Service A are logically separate, physical implementation may combine them. While PDP B is logically separate from Resource B, logical implementation may be as an externalized PEP or Internalized Code An example of this is an IdP or SP initiated Web Browser SSO in which the subject authenticates to an IdP in its own domain and is redirected to the SP. The redirect session contains both an authentication assertion and an attribute assertion. The SP validates the authentication assertion and a PEP/PDP integrated with the SP utilizes the attributes in the attribute assertion to make an access control decision. This, with minor variations, also supports user centric flows using information cards etc. Authorization – Back Channel Attribute Based Access Control Clear separation of security boundaries Clear separation between Authentication and Authorization Resource B needs attributes of Subject A to make access control decision Resource B is requires delivery of Subject A attributes directly from authoritative sources Subject A’s is authenticated using one of the cross-domain brokered authentication Flows Supports both Brokered I and Brokered II Authentication Flows 1) Subject A’s access control decision has been externalized to PDP B 2) PDP B makes pulls attributes directly from authoritative sources and an access control decision based on attributes that have been gathered While Broker A and Attribute Service A are logically separate, physical implementation may combine them. While PDP B is logically separate from Resource B, logical implementation may be as an externalized PEP or Internalized Code An example of this flow is a Subject who authenticates in its own domain using an IdP or SP initiated Web Browser SSO or a subject who authenticates using an X.509 based Smart Card to the Resource. Once the subject has been validated, the access control decision is delegated to a PDP which pulls the attributes of the subject directly from authoritative sources using one of the supported Attribute Exposure Flows. Provided the infrastructure exists, there is nothing stopping you from using a combination of both Front Channel and Back Channel mechanisms for ABAC. For example, you may want to have the option of the Subject mediating privacy related attribute release via the Front Channel and combine that with Enterprise or Community of In[...]
Federation Flows 2 – Attribute Exposure 2011-06-05T15:18:28.628-04:00 Continuing my series of blog posts on the options available in federating identities, which I started with Authentication, I am going to try and map out some options that are available when exposing attributes. As noted in my earlier post on Authentication, the following caveats apply: This is conceptual in nature Implementation choices, whether they are architectural or technology, may drive the separation or co-location of some of the conceptual entities noted in the pictures Still a work in progress… Attribute Exposure – Organizational Query Clear separation of security boundaries. One or more authoritative sources of attributes for the Subject exist in the same Trust Domain Trust relationship between Resource B and Attribute Service A set up before-hand and out-of-band 1) Subject A has been Authenticated in Trust Domain B 2) Resource B recognizes Subject A as from outside its domain and utilizes attributes from Attribute Service A Attribute Exposure – Single Point of Query 1 Clear separation of security boundaries. One or more authoritative sources of attributes for the Subject exist in multiple Trust Domains Trust relationship between Resource B and Attribute Aggregator A set up before-hand and out-of-band Attribute Aggregator A has knowledge and trust relationships with attribute sources both inside and outside its trust domain 1) Subject A has been Authenticated in Trust Domain B 2) Resource B recognizes Subject A as from outside its domain and utilizes attributes from Attribute Aggregator A 3-4) Attribute Aggregator A aggregates Subject A attributes from multiple authoritative sources, wherever they may reside Attribute Exposure – Single Point of Query 2 Clear separation of security boundaries One or more authoritative sources of attributes for the Subject exist in multiple Trust Domains Resource B has outsourced attribute gathering to Attribute Aggregator B Attribute Aggregator B has knowledge and trust relationships with multiple attribute sources 1) Subject A has been Authenticated in Trust Domain B 2) Resource B recognizes Subject A as from outside its domain and utilizes attributes from Attribute Aggregator B 3-4) Attribute Aggregator B aggregates Subject A attributes from multiple authoritative sources, wherever they may reside I am most ambivalent regarding this flow because of the complexity of the moving pieces involved: The multiple trust relationships that needs to be managed by the attribute aggregator The attribute aggregator must “know” where all to go to get the attributes, but given that the subject is from a separate domain and the aggregator may not have a close enough relationship with the subject, would it really know where to go to get the attributes? Attribute Exposure – Identity Oracle Clear separation of security boundaries One or more authoritative sources of attributes for the Subject exist in multiple Trust Domains Resource B has engaged the services of an Identity Oracle Identity Oracle has close relationship with multiple Authoritative Attribute Sources 1) Subject A has been Authenticated in Trust Domain B 2) Resource B recognizes Subject A as from outside its domain and asks appropriate question of the Identity Oracle 3-4) Identity Oracle obtains relevant Subject A attributes from multiple authoritative sources and answers the question I am being very car[...] |
|||||||||||||||||||
http://feeds.feedburner.com/aniljohn
Copyright 2006-2012 Feedage.com LLC
Privacy policy - Sitemap - Press - Terms of Service - Copyright information
Contact Us - About Us - Feedage - Search Engine Consulting
Language Detection Powered by
Privacy policy - Sitemap - Press - Terms of Service - Copyright information
Contact Us - About Us - Feedage - Search Engine Consulting
Language Detection Powered by