Awesome! I hope this act wins!

Federating identities across information and security domains is not just a technical problem, and anyone who tells/sells you that it is, is not operating in a frame of reality that is conducive to success!

Please note that, for me, an implementation of an Identity Federation architecture takes into account both Authentication and Authorization as well as a host of other areas.  As such I've always found it amusing to be informed (usually by a vendor) that this is a straight forward problem and that once I deploy [Insert technology / tool / product / magic pixie dust of choice here], we will have you "federating in no time". Ha!

We have been wrestling with this and at one of our working meetings recently, one of my team-mates came up with the following representation to describe the challenges of reaching agreement on what information needs to flow across federation boundaries, and what needs to be in place to accomplish it. Based on the same principle as the Boy Scout's triangle (heat, oxygen, fuel), you take away one side, and the entire Attribute Triangle (or as we call it, "Tom's Triangle", in honor of our team-mate who came up with it) collapses.

When you look at it, it seems so obvious and simplistic, but we have found value in thinking thinking about it in this manner.  Organizational Policy determines the rules of the road. Those rules in turn are reflected in the choices of attributes and the agreements around their semantics. At the same time, you need to be assured that the agreed upon attributes are not things that you come up out of the blue but are instead drawn from trusted and authoritative sources in the Enterprise.

"... part of our job is to make deliveries of metal to deserving customers. Business is Good!"

An excerpt from a conversation with an Army Colonel.

GSA's USA Services/Intergovernmental Solutions sponsors monthly workshops around topics such as emergency preparedness, environmental monitoring, healthcare and law enforcement.

The upcoming "Exploring Identity Management: Global Landscape and Implications for Stakeholder Engagement Around the National Response Framework" session is focused on the implications of the "National Response Framework [PDF]" to Identity Management.

National Response Framework (NRF) is a guide to how the Nation conducts all-hazards response.  It is built upon scalable, flexible, and adaptable coordinating structures to align key roles and responsibilities across the Nation, linking all levels of government, nongovernmental organizations, and the private sector.  It is intended to capture specific authorities and best practices for managing incidents that range from the serious but purely local, to large-scale terrorist attacks or catastrophic natural disasters.

I had the opportunity to speak with both Susan Turnbull at the GSA as well as Dr. Duane Caneva, Director of Medical Preparedness at the White House Homeland Security Council, who are putting this event together, and came away impressed with their obvious passion in addressing this critical issue.

Basically, this is all about the technical, social and organizational infrastructure that needs to be in place to respond to a Katrina-like or Tsunami-like event.  Identity Management is seen as an enabler in bringing the right people, the right resources and the right information together to help make a difference in responding to a crisis of this magnitude.

I also came away with an action item to discuss with this community how some of the work that I am currently involved with could help out in this particular domain.  The agenda looks pretty interesting and builds upon past events such as the IDTrust 2008 etc. Looking forward to this!

I typically don't do this, but this particular job opening in my organization is for someone that I will be directly working with.  As such, it is in my best interest to make sure that the opening gets socialized to folks in the right communities so that I can continue to work with folks who are a whole lot smarter and more knowledgeable than I am

So if you have a knowledge base that spans identity, security and privacy technologies, would like a job that has a direct impact on and enhances of the security of the nation, and would like to work in an environment that values your individual contributions to a kick-ass team, we are hiring! 

Here are some of what I consider to be the relevant details of the job opening. The full description of the job, as well as how to apply for it, can be found on the official job requisition.

The ideal candidate will have a knowledge base that spans identity, security and privacy technologies as well as the ability to bridge the software development and computing infrastructure domains.

Duties:

• Provide subject matter expertise in implementing identity and access control solutions in support of a variety of sponsors in the Government and Intelligence Communities. [...]
• Maintain current knowledge of identity technologies in the commercial marketplace with an eye towards how it could be applied to sponsor needs. Expectation is that the candidate actively participates in the technical community [...]
• Actively work to share knowledge and experience gained in external community participation and project work via participation in internal Communities of Practice, online forums [...]
• Participate in standards organizations such as OASIS, W3C and others on behalf of JHU/APL in the creation and modification of standards [...]

Desired:

• Self-motivated to learn and apply technology to solve problems
• Ability to “Argue like you are right, Listen like you are wrong”
• Self-starter who proactively searches for and obtains potential solutions to problems
• Demonstrated experience with the implementation of identity solutions which may include:
  • Application of relevant standards such as SAML, XACML, WS-SX, etc.
  • Implementation and/or administration of directory services (LDAP etc) and/or Virtual Directory Capabilities,
  • Implementation and/or administration of PKI,
  • Implementation and/or administration of Web Access Management solutions
  • RBAC/ABAC
• Full lifecycle implementation experience as related to an Identity Management Project

Required:

• Demonstrated experience in one or more of the relevant areas of Identity, Security, and Privacy with an interest in focusing on the Identity Management area.
• At least 5 years of increasingly complex software development with one or more of the major software platforms (i.e. .NET and/or JEE) and/or infrastructure experience with one or more major operating systems (i.e., *nix, Windows) in an Enterprise class environment
• Awareness of the fundamental principles of Service Oriented Architecture
• Must be eligible for US Department of Defense (DoD) clearance requiring background investigation and/or polygraph examination.  [Please be aware that holding a U.S. Citizenship is part of the requirement for obtaining a security clearance]
• [...]

If you are interested, apply via the official job site, but in addition, drop me a note that you have applied with your attached resume to my work e-mail (anil dot john -at- jhuapl dot edu), so that I can have it flagged internally and properly routed.

If you would simply like to find out more about the job, the work environment etc, or would like any clarifications before you take action, please feel free to contact me.  Needless to say, if you know of someone else who would be interested, please pass the details on to them.

A new “Information Sharing Strategy” (PDF) from the Office of the Director of National Intelligence warns that traditional security practices that restrict disclosure of information have become counterproductive.

“The Intelligence Community’s ‘need to know’ culture, a necessity during the Cold War, is now a handicap that threatens our ability to uncover, respond, and protect against terrorism and other asymmetric threats,” the document declares.

The new Strategy defines information sharing goals and as well as near-term and long-term implementation objectives. Goals include uniform government-wide information policies, improved connectivity, and increased inter-agency collaboration.

Source: FAS Project on Government Secrecy

The document notes that in order to achieve their information sharing vision, the IC has "...  adopted a new information sharing model, which is depicted in Figure 1:"

Just picked up the current issue of IEEE Security & Privacy Magazine and it is full of Identity Management Goodness!

• I'm Pc01002/SpringPeeper/ED288l.6; Who are You? by Susan Landau and Deirdre K. Mulligan
• The Venn of Identity: Options and Issues in Federated Identity Management (Abstract) by Eve Maler and Drummond Reed
• The Seven Flaws of Identity Management: Usability and Security Challenges (Abstract) by Rachna Dhamija and Lisa Dusseault
• Biometrics in Identity Management Systems (Abstract) by James L. Wayman
• Privacy and Identity Management (Abstract) by Marit Hansen, Ari Schwartz and Alissa Cooper
• Identity Management, Privacy, and Price Discrimination (Abstract) by Alessandro Acquisti
• Use Cases for Identity Management in E-Government (Abstract) by Robin McKenzie, Malcolm Crompton and Colin Wallis
• Dynamic Security Assertion Markup Language: Simplifying Single Sign-On by Patrick Harding, Leif Johansson, and Nate Klingenstein

Looking forward to this read!

Some time ago, I was having a conversation with some folks about the usage of SAML Authentication Assertions for Web Browser Single Sign-On (SSO) versus Digital Certificates.  The folks that I was having this conversation with support one of the larger PKI deployments in the US, and their response to my comment about the lack of support for SAML for Web Browser SSO in that particular vertical was the following question:

"Provided the experience to the user is the same, why does it matter?"

I didn't have a very good answer at that point in time but it is something that I've been mulling over since that time. The issue has come up again in separate conversations, including this one by Patrick Harding of Ping Identity and this posting by James McGovern.  This blog posting is an attempt to articulate some of the points on both sides of this debate.

SAML 2.0 and Web Browser SSO

The Web Browser SSO Profile in SAML 2.0 supports both an Identity Provider (IdP) initiated and Service Provider (SP) initiated SSO message flows. As described in the SAML documentation ".. the most common scenario for starting a web SSO exchange is the SP-initiated web SSO model which begins with the user choosing a browser bookmark or clicking a link that takes them directly to an SP application resource they need to access. However, since the user is not logged in at the SP, before it allows access to the resource, the SP sends the user to an IdP to authenticate. The IdP builds an assertion representing the user's authentication at the IdP and then sends the user back to the SP with the assertion.  The SP processes the assertion and determines whether to grant the user access to the resource.

In an IdP-initiated scenario, the user is visiting an IdP where they are already authenticated and they click on a link to a partner SP. The IdP builds an assertion representing the user's authentication state at the IdP and sends the user's browser over to the SP's assertion consumer service, which processes the assertion and creates a local security context for the user at the SP."

Some points to keep in mind regarding these two flows:

• The user's credentials are maintained at their IdP, which means that the SP must trust the IdP to assert information about its users. The establishment of this "organizational trust" is typically done out of band.
• The IdP can support multiple authentication mechanisms of varying strengths including user-id/password, software certificates and smart-cards based on a PKI, biometrics etc.
• The type and the strength of the authentication used by the user can be conveyed in a SAML authentication context which can be used in (or referred to from) a SAML Authentication Assertion. In fact an SP can include an authentication context in a request to an IdP to request that the user be authenticated using a specific set of authentication requirements, such as a multi-factor authentication.
• Do not conflate authentication with authorization! Although the user has been authenticated, the SP more than likely needs a LOT more information about the user (than what was provided in the Authentication Assertion) in order to make an access control decision.  This typically requires the usage of SAML attribute statements and/or SAML authorization decision statements. And in any reasonably complex environment that wants to remain standards based, this more than likely involves the usage of XACML for defining access control criteria.
• SAML supports mechanisms to support the integrity and confidentiality of the assertions themselves including SSL mutual authentication, XML Signature etc. and does so across both the HTTP and SOAP bindings.

PKI and Web Browser SSO

This is pretty straight forward from the usage perspective. It begins with a user choosing a bookmark or clicking a link that takes them directly to a Relying Party (RP) i.e. application resource they need to access.  The user is prompted to present a digital certificate as the authentication mechanism.  The user's certificate, whether it is in the form of a soft certificate or coming from a smart card, is used to authenticate the user.

Some points to keep in mind:

• In a PKI environment, when a Certification Authority issues a certificate, it is making a statement to a RP that a particular public key is bound to a specific entity (i.e. the subject of the certificate).
• The degree to which a RP trusts a CA is based on the RP's understanding of the CA's user identification and credential issuance practices, operating policies, security controls etc.
• Depending on the identity issuance requirements of a CA, the digital certificate is usually consider a higher assurance authentication mechanism than something like a user-id and password.
• Each RP has to put into place the technical infrastructure needed to make it PKI-aware i.e. the ability to use digital certificates as authentication mechanism.
• Each RP has to put into place the mechanisms for both validation and revocation operations. This is especially challenging when you have CA's that are cross-certified and CA's and clients need to support certificate path processing.
• The user experience, in browsing from one PKI protected resource to another may not be seamless.
• The authorization aspect is indeed separate from the authentication.  Information needed to make an access control decision may not be present in the information provided by a digital certificate.

What strikes me when I look at these two options is that the question posed at the start of this entry may not be the right one to ask. The question one should be asking instead is "Who do you trust?"

The fundamental precept of a PKI environment is that everyone must buy into trusting the CA. I would bet that that a lot of the "entrenched PKI communities" have expended significant amount of resources in standing up not just the technical infrastructure but the credential proofing and issuance processes for their domain. As such, they implicitly trust a certificate vouched for by the CA. The downside to this is that every single RP must be PKI-enabled, which is non-trivial.

SAML is not a trust mechanism but more of a mechanism for a particular domain to make assertions about its users. As such, what is needed in the federated world for this to work is for a relying domain to trust the asserting domain. The relying domain would have to have confidence in the credential proofing and issuance process of the asserting domain. The advantages here would be that SAML-enabling an SP is a more straight forward process and there is significant out-of-the-box support for SAML in vendor tooling.

In each case, I consider authorization to be separate and distinct from the authentication.

But that organizational trust... Ah!  Is it not remarkable that the truly hard problems, whether one is discussing Identity Management or Service Orientation, really do not have to do with technology but with people, culture and behavior?

Series of posts on threat modeling. Good stuff!
[Found via Bruce Schneier]

• The Trouble with Threat Modeling
• The New Threat Modeling Process
• Getting into the Flow With Threat Modeling
• Making Threat Modeling Work Better
• Threat Modeling Self Checks and Rules of Thumb
• The STRIDE per Element Chart
• Wrapping up Threat Modeling

Also check out JD's post on Getting Started with Threat Modeling and the Threat Modeling Blog maintained by the Microsoft Application Consulting and Engineering Team.