Anil John

OpenSSL stateOrProvinceName and Microsoft Interop Issue

Anil John — Fri, 15 Jan 2010 03:41:12 GMT

I am currently conducting some testing involving SAML Attribute Authorities. We are currently using an OpenSSL based CA to issue the digital signature and encryption certificates used to provide message level security for all entities involved. In particular, this allows us to encrypt the response to an attribute query using the public key of the requester such that only the requester is able to decrypt the response using their corresponding private key.

Today I got a call from one of the vendors who have been testing against us noting that they were having issues decrypting the response. They did some troubleshooting on their end and noted that the stateorProvinceName part of the certificate's Subject DN that they were seeing on their end was NOT matching what was coming across in my response.

Specifically on their end, the stateorProvinceName part of the Certificate DN looked like "S=MD" while what I was returning was "ST=MD".

In the course of troubleshooting the problem on my end, I checked out the openssl.cfg file for the CA. It was set up correctly.

I then looked at the public certificate that was generated (pem format). It too had State in the format that I was expecting (ST=MD).

I also pulled up the certificate in a java tool called Portecle which allows you to work with keystores etc. Same result.

The interesting thing about this particular vendor is that their product is built on top of Windows, .NET and WCF. So their usage of digital signatures and encryption/decryption functionality is leveraging Microsoft technologies and the.NET platform. So I changed the pem extension on the public certificate to cer and opened it on my Windows desktop.

And there it was... "S=MD"

From what I understand, per RFC 2256 which is Normative for LDAP, the correct field name for "STATE" is st which "... contains the full name of a state or province (stateOrProvinceName)".

If I can extrapolate what I am seeing here, it would appear that both the UI in Windows and the programmatic access to this information is via the same API, which is telling them S=MD.

I did a bit of search on the web and this issue seems to have up in some cases regarding Windows 2003 certificate services, so I don't think I am alone here. I also believe that I have done everything right on how the key-pair itself is generated.

But I am at a bit of stand still as I am not sure of what guidance to provide the vendor. Some questions that I have are:

Is this a known problem, or is this being caused by some oversight/mistake on my part (would not be the first time)?
Is there any particular function/API call that someone working in .NET/WCF could use such that they are working with the actual Subject Name?

I am hoping that people out there have encountered this issue, identified where the problem is, and come up with some sort of a solution. Any pointers would be deeply appreciated.

del.icio.us Tags: OpenSSL,CertServ,X.509,stateorProvinceName,Microsoft

Technorati Tags: OpenSSL,CertServ,X.509,stateorProvinceName,Microsoft

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 Attribution 3.0 License.

Cloud Computing Thoughts from Catalyst09

Anil John — Fri, 14 Aug 2009 13:59:16 GMT

I had a great time at Burton Group's Catalyst Conference this year. Spent my time between the Identity Management, SOA and Cloud sessions. Also had an opportunity to attend the Cloud Security & Identity SIG session as well.

As the fast-thinking, slow talking, and always insightful Chris Haddad notes on the Burton APS Blog (Chris... enjoyed the lunch and the conversation) "Existing Cloud Computing's momentum is predominantly focused on hardware optimization (IaaS) or delivery of entire applications (SaaS)".

But the message that I often hear from Cloud vendors is:

We want to be an extension of your Enterprise
We have deep expertise in certain competencies that are not core to your business, and as such you should let us integrate what we bring to the table into your Enterprise

... and variations on this theme.

But in order to do this, an Enterprise needs to have a deep understanding of its own core competencies, have clearly articulated it's capabilities into distinct offerings, and gone through some sort of a rationalization process for its existing application portfolio.. In effect, have done a very good job of Service Orient-ing themselves!

But we are also hearing at the same time that SOA has lost its bright and shiny appeal and that most SOA efforts, with rare exceptions, have not been successful. For the record, success in SOA to me is not about building out a web services infrastructure, but about getting true value and clear and measurable ROI out of the effort.

So to me, it would appear that without an organization getting Service Orientation right, any serious attempt they make on the cloud computing end will end up as nothing more than an attempt at building a castle on quicksand.

The other point that I noted was that while there were discussions around Identity and Security of Cloud offerings (they still need to mature a whole lot more, but the discussion was still there), there was little to no discussion around visibility and manageability of cloud offerings. A point that I brought up in questions and in conversations on this topic was that while people's appetite for risk vary, one of the ways to evaluate and potentially mitigate risk was to provide more real time visibility into cloud offerings. If a cloud vendor's offerings are to be tightly integrated into an Enterprise, and I now have a clear dependency on them, I would very much want to have a clear awareness of how the cloud offerings were behaving.

From a technical perspective, what I was proposing was something very similar in concept to the monitoring (and not management) piece of what WS-Management & WSDM brought to the table on the WS-* front. In effect, a standardized interface that all cloud vendors agree to implement that provides health and monitoring visibility to the organizations that utilize their services. In short, I do not want to get an after-the-fact report on your status sent to me by e-mail or pulled up on a web site, I want the real time visibility into your services that my NOC can monitor. There was a response from some vendors that they have this interface internally for their own monitoring. My response back to them is to expose it to your customers, and work within the cloud community to standardize it such that the same interface exits as I move from vendor to vendor.

del.icio.us Tags: SOA,Cloud Computing,Security,Management,#Catalyst09

Technorati Tags: SOA,Cloud Computing,Security,Management,#Catalyst09

SAML v2 Testing and soapUI

Anil John — Sun, 21 Jun 2009 00:40:19 GMT

As part of the BAE profiling and reference implementation, we have a full test & validation suite. Our desire has always been to make the barrier to entry for anyone using the test suites to be the minimum it needs to be. As such we focused on creating our test suites using open source tooling so that we could provide a test suite project that an implementer could import into their open source testing tool, point it at their BAE implementation, run it, and get immediate feedback on whether or not their implementation was conformant to the profile.

To that end, we have been using the popular and free soapUI testing tool. Unfortunately, we are running into some limitations in the tool support for SAML 2.0. It would appear that the current soapUI implementation is using the OpenSAML 1.1 implementation and not the current OpenSAML 2.0 which supports SAML v2. In particular, this means that the following functionality that relates to the testing of SAML AttributeRequest/Response are not supported:

Ability to digitally sign and validate attribute requests and responses using the enveloped signature method
Ability to utilize the <saml:EncryptedID> as a means of carrying the encrypted name identifier
Ability to decrypt the <saml:EncryptedAssertion> element sent by the Attribute Authority which contains the encrypted contents of an assertion

This has required us to go thru some gyrations in how we are implementing the test suites, which is making the user experience not as smooth as we would like.

Ideally we would love to continue using soapUI going forward, but we are also on the lookout for other open source tooling that we could utilize for our testing. Suggestions and recommendations from folks who have experienced this issue and have found a resolution would be very much appreciated.

del.icio.us Tags: SAML,BAE,Profile,Testing,soapUI

Technorati Tags: SAML,BAE,Profile,Testing,soapUI

Beverly Hills Cops (and IT)

Anil John — Sat, 20 Jun 2009 23:24:09 GMT

I had the opportunity last week to visit with the Beverly Hills Police Department as well as their CIO and his staff. My areas of discussion with them were primarily focused around Information Security and Identity and Access Management.

Found them to be a very impressive organization, from the technical infrastructure they have in place, their desire to leverage information technology for the benefit of their customer base (both government and residents), as well as the partnerships that they have forged across many different arenas.

It was particularly interesting to hear the comments from them about how they are a sought after employer by some very talented people because of the very interesting projects that they work on and the technologies that they get to utilize. As a technologist, I definitely enjoyed their data center tour as well as an overview of upcoming capabilities that they are working on. Very cool stuff.

Funniest moment: Walking back from lunch with the Chief of Police. Waiting to cross the street. A young guy in front of us starts to Jaywalk! Instant shout from the Chief "Hey, Hey, What are you doing?" It was like watching the guy hit a rubber band. Instant backpedaling back to the sidewalk with an mumble that he thought the light was green. Punch-line: Chief is in business clothes. Not in uniform. Sheer authority in voice got the response!

P.S. Yes, please spare me the Eddie Murphy jokes; By now, I have heard them all :-)

del.icio.us Tags: BHPD,Travel,BeverlyHills

Technorati Tags: BHPD,Travel,BeverlyHills

SAML2 Profiles for PIV Subjects and Backend Attribute Exchange

Anil John — Sat, 06 Jun 2009 18:59:21 GMT

FIPS 201 defines a US Government-wide interoperable identification credential for controlling physical access to federal facilities and logical access to federal information systems. The FIPS 201 credential, known as the Personal Identity Verification (PIV) Card, supports PIV Cardholder authentication using information securely stored on the PIV Card. Some PIV Cardholder information is available on-card through PIV Card external physical topology (i.e., card surface) and PIV Card internal data storage (e.g. Magnetic stripe, integrated circuit chip).

Other PIV Cardholder information is available off-card. Examples of off-card information, say in the First Responder & Emergency Response domain, could be certifications that could be presented by a Doctor or EMT that could verify their claims and allow physical and/or logical access to resources.

Accordingly, the federal government requires a standard mechanism for Relying Parties to obtain PIV Cardholder information (User Attributes), which are available off-card, directly from the authoritative source (Attribute Authority). The authoritative source is the PIV Card Issuing Agency, which is the agency that issued the PIV Card to the PIV Cardholder. The exchange of these User Attributes between backend systems is known as “Backend Attribute Exchange” (BAE). The architectural vision for the BAE can be found at IDManagement.gov (Direct link to "Backend Attribute Exchange Architecture and Interface Specification" - PDF).

I, and members of my team, have been part of a joint DHS and DOD team that have been working on a proof of concept implementation of the BAE in order to validate the approach, gain valuable implementation experience, and to provide feedback to the relevant governance organizations within the US Federal Government. The results of our work are three-fold:

A SAML2 Profile of the BAE, with both normative and informative sections, that provide concrete implementation guidance, lessons learned as well as recommendations for folks seeking to support this profile
Reference implementations stood up within the T&E environments of both DHS and DOD for interoperability testing
Test suites that can be used by implementers to verify compliance with the profile

I am happy to report that the profile is currently at v1.0 (DRAFT) status, under external review, and that we are scheduled to give a briefing on the work to a sub-committee of the Federal CIO Council later this month. In addition, we have our reference implementations up and running and are putting the finishing touches on the Test Suites.

As someone who has and is participating in industry standards efforts, I am fully aware that one of the critical items for a standard to become successful is for incorporation of the standard into vendor tooling. Some of the choices that we made, beyond satisfying the needed functionality, was to make sure that it was as easy as possible to build in profile support by:

Not reinventing the wheel; Leverage the conventions and standards established by some of the fine work that has been done to date by the OASIS Security Services (SAML) TC on Attribute Query Profiles
Keep the delta's as small as possible between the BAE Profile and existing profiles such as the X.509 Attribute Sharing Profile (XASP)
Provide LOTS of informative guidance
Striking a balance between making sure that the profile was generic enough to be widely used and deployable, but provided enough information in the message flow for implementers to get full value.

The last item was something that we found to be critical and sometimes contentious to balance. But, we would not be where we are right now, had we not been informed by our actual proof-of-concept implementations. A pure paper effort would have left too many holes to patch.

We have also made an active effort to reach out to vendors, especially in the federation, entitlement management and XML security arenas, and have been gratified by their response in committing to support this profile in their tooling (In some cases, folks already have beta support baked in!). We are fully expecting to highlight and point out those folks during our out-brief later this month. If you are a vendor, want to find out what it takes to support this profile, and are interested in receiving a copy of the v1.0 DRAFT, please feel free to ping me at anil dot john at jhuapl dot edu.

This has been a pretty extensive, exciting and detailed effort and we are very grateful for the senior level support from both Organizations for this effort. Beyond that, it has been a blast working with some very smart people from both DHS and DOD to make this real.

del.icio.us Tags: SAML,BAE,Profile,DOD,DHS,ABAC,Attributes

Technorati Tags: SAML,BAE,Profile,DOD,DHS,ABAC,Attributes

NORAD and Santa Tracking

Anil John — Tue, 23 Dec 2008 01:17:28 GMT

Especially for those with young kids (This has now become a Christmas Eve tradition at our house) ...

Continuing a more than 50 year old tradition, NORAD (North American Aerospace Defense Command) will be tracking Santa on his Christmas Eve flight across the world. You and your kids can track Santa on NORAD's Track Santa web site.

A big "Thank You" to the men and women of NORAD, who have selflessly volunteered their time to personally update children via phone calls, emails and the Internet on Christmas Eve. Some further information:

del.icio.us Tags: Santa,NORAD

Technorati Tags: Santa,NORAD

Reality of XACML PEP-PDP Interoperability - Part II

Anil John — Sun, 14 Dec 2008 00:50:27 GMT

In another context, I was recently asked:

Since you first posted your article about interoperability, did you find out "Who among you actually implement this interoperable interface specification in your current shipping product?"

Thought I'd share the relevant bits of the answer that I gave:

"... before I answer your question, please know that the focus for my environment was/is on building out a policy driven infrastructure for a web services environment. And the motivations for going down that path include:

Consistent enforcement of policy (and in this particular case, access control policy) across multiple services

Minimize the number of interception points in the message path

Take the burden/complexity/headache of security policy out of the hands of the development teams who are deploying the services and move it into the infrastructure

As such, what I was particularly interested in having happen is for the XML Security Gateways in my environment to act as a XACML PEP to a remote XACML PDP. So to answer your question, you need to look at both the PEP and the PDP side:

One the PEP side, the answer is “It depends” on how flexible the product is. *Most* of the gateways provide you some mechanism for making an external “call-out” as part of the decision making process. i.e. Incoming request comes in to the PEP; PEP intercepts, does some basic threat and malicious content scanning, Authenticates the user/entity, then formulates an AuthZ request, sends it out in an “external call-out” to a PDP, and acts on the decision when it is returned. The ease of how you can do this, and the ability to customize that call-out depends on the particular product. You basically have on one extreme the need to engage the consulting services of the vendor to customize that call, to the other of being able to have the ability to do-it yourself using nothing more than message templates. So in short, you can bend the metal to make the PEPs generate a XACMLAuthzDecisionQuery and I am aware that at least a couple of the vendors in this space have it on the roadmap to be a native XACML PEP, but I am unsure of exactly what they mean by that term.

On the PDP side, what I will say is that silence as answer to the question is an answer in itself.. :-) Pretty much all of the PDP vendors have some sort of a web service interface to their “Authorization Service”. To date my experience working with multiple products (both on the PEP and the PDP side) has been that you simply cannot point a PEP to PDPs implemented by multiple vendors and expect it to work without custom “franken-code” on either/both the PEP and PDP ends (Even though this was exactly the point of the Catalyst Demo that I noted in my blog entry).

These days my response to the vendor response of “Oh, Sure we do that!” is a request for a pointer to the WSDL and the XSDs of their Authorization/Entitlement Service of their current shipping product to prove that they indeed do it. For some reason, the conversation seems to just die out at that point … <shrug>"

As always, if my understanding is incomplete or incorrect, please feel free to leave a comment on this blog entry.

del.icio.us Tags: XACML,PEP,PDP,Interop

Technorati Tags: XACML,PEP,PDP,Interop

Reality of XACML PEP-PDP Interoperability

Anil John — Sun, 28 Sep 2008 04:11:50 GMT

What is the current state of interoperability between XACML PEPs and PDPs from different vendors? I am currently looking to see if there is a consistent implementation of PDP interfaces among the multiple Fine Grained Authorization/Entitlement vendors such that I can point a XACML PEP from one vendor to the XACML PDP of multiple vendors and not have to do custom integration to make it work.

Back in February 2007, Burton Group issued a challenge to the the industry to demonstrate interoperability of XACML. Some of the questions they asked were "Can enterprises really mix and match policy administration points (PAPs), policy decision points (PDPs), and policy enforcement points (PEPs) from different vendors? Is the XACML RBAC Profile practical? Or will we find that different interpretations of the specification yield less than satisfactory levels of interoperability?"

The industry responded, via the OASIS XACML TC, in June 2007 by having the first XACML Interoperability Demo at the Burton Group Catalyst conference. There were two particular use cases in this demo, which required interoperability between vendor implementations of PEPs, PDPs and PAPs:

Authorization Decision Request/Response
Policy Exchange

I am particularly interested in the first scenario and in looking at the interop scenario document, it would appear that some specific choices were made in order to make this work:

Implementation of the XACML Interface of the PDP as a SOAP Interface which accepts a XACMLAuthzDecisionQuery and returns a XACMLAuthzDecisionStatement which are contained in the SOAP body.
Use of the SAML 2.0 Profile for XACML 2.0 which defines a Request/Response mechanism for carrying xacml-context:Request and xacml-context:Response elements.

In effect, what you ended up with in order to make this work is the implementation of a standardized SOAP interface that adhered to the following Request/Response (Taken from the interop scenario document):

Sample SOAP SAML XACML Request wrapper:

Sample SOAP SAML XACML Response wrapper:

I attended this event and remember coming away impressed at the results while simultaneously amused at some of the coding heroics of the vendors who, if I remember correctly, in some cases had very short time frames to work with.

It has now been more than a year since this interop event and at this point I have a very simple question for the vendors in this space "Who among you actually implement this interoperable interface specification in your current shipping product?"

From what I see to date (and I am more than happy to be corrected on this point) is that while many vendors claim conformance and implementation of the XACML 2.0 standard, their PDP interfaces are still proprietary and unique. Oh, don't get me wrong, these interfaces may be implemented using web services etc. BUT each web service implementation is unique and special to that vendor and does not follow any consistent interface specification and as such is an integration exercise that is left up to implementers if you have PEPs from multiple vendors. e.g. XML Security Gateways or Software PEPs from multiple vendors which need to talk to a XACML PDP.

del.icio.us Tags: XACML,PEP,PDP,Interop

Technorati Tags: XACML,PEP,PDP,Interop

Information Disclosure Threats and Web Services

Anil John — Sun, 21 Sep 2008 19:09:18 GMT

In the physical world, when an attacker is preparing to assassinate someone or bomb a target, the first thing that they will do is to determine how best to set up that attack. The phrase used to describe the initial phase of the set-up is called 'pre-operational surveillance'.

Unfortunately, the default configuration of most web services allow a potential attacker to do the digital equivalent of pre-operational surveillance very easily. In the digital world, these type of threats are often classified under the category of 'Information Disclosure Threats'. There are two in particular (there are more) that I would like to call attention to:

SOAP Fault Error Messages
WSDL Scanning/Foot-Printing/Enumeration

1. SOAP Fault Error Messages

All too often, detailed fault messages can provide information about the web service or the back-end resources used by that web service. In fact, one of the favorite tactic of attackers is to try to deliberately cause an exception or fault in a web service in the hope that sensitive information such as connection strings, stack traces and other information may end up in the SOAP fault. Mark O'Neill has a recent blog entry 'SOAP Faults - Too much information' in which he points to a vulnerability assessment that his company did of a bank that provided information that enabled an attacker to understand the infrastructure the bank was running and presumably allowed them to further tailor the attack.

The typical mitigation for this type of information disclosure is the implementation of the 'Exception Shielding Pattern' as noted in the Patterns & Practices Book 'Web Service Security' [Free PDF Version] which can be used to "Return only those exceptions to the client that have been sanitized or exceptions that are safe by design. Exceptions that are safe by design do not contain sensitive information in the exception message, and they do not contain a detailed stack trace, either of which might reveal sensitive information about the Web service's inner workings." (FULL DISCLOSURE: I was an external, unpaid, technical reviewer of this book).

You can either implement this pattern in software or use a hardware device like a XML Security Gateway to implement this pattern. Mark utilized a Vordel Security GW, but this is something that can be implemented by all devices in this category. I have direct experience with Layer 7 as well as Cisco/Reactivity Gateways and happen to know that they support this functionality and I don't doubt that IBM/DataPower and others in this space support it as well.

Note that this does not imply that the error's that happen are not caught or addressed but simply that they are not propagated to an end-user.

2. WSDL Scanning/Foot-Printing/Enumeration

Appendix A of 'NIST 800-95: Guide to Secure Web Services' provides a listing of common attacks against web services, and you will note that there are many references to the information that can be found in a WSDL that can lend itself to a variety of attacks including Reconnaissance Attacks, WSDL Scanning, Schema Poisoning and more.

And in the 'Security Concepts, Challenges, and Design Considerations for Web Services Integration' article at the "Build Security In" web site sponsored by the DHS National Cyber Security Division, it notes that "An attacker may footprint a system’s data types and operations based on information stored in WSDL, since the WSDL may be published without a high degree of security. For example, in a world-readable registry, the method’s interface is exposed. WSDL is the interface to the web services. WSDL contains the message exchange pattern, types, values, methods, and parameters that are available to the service requester. An attacker may use this information to gain knowledge about the system and to craft attacks against the service directly and the system in general."

The type of information found in a WSDL, and which can be obtained simply by appending a ?WSDL to the end of a service endpoint URL, can be an extremely useful source of info for an attacker seeking to exploit a weakness in a service, and as such should not be provided or simply turned off.

There are multiple ways of mitigating this type of an attack which include turning off the automatic ?WSDL generation at the SOAP stack application level or by the configuring the intermediary that is protecting the service end-point. For example, most XML Security Gateway's by default turn off the ability to query the ?WSDL on a service end-point.

I consider this to be a very good default.

When this option is implemented, there are often a variety of questions that come up that I would like a take a quick moment to address.

Q. If you turn off the automatic WSDL generation capabilities (i.e. ?WSDL) how are developers supposed to implement a client that invokes the web service?

There are two ways. (1) Publish the WSDL and the associates XML Schema and Policy files in an Enterprise Registry/Repository that has the appropriate Access Control Mechanisms on it so that a developer can obtain a copy of the WSDL/Schema/Policy Documents at design time. (2) Provide the WSDL/Schema/Policy files out of band (e.g. Zip File, At a protected web site) to the developer.

Oh yes, there is always the run-time binding question that comes up here as well. What I will say is that run-time binding does not mean "run time proxy generation + dynamic UI code generation + glue code" but simply that the client side proxy and the associated UI and glue code are generated at design time, but that the end-point that the client points to may be a dynamic lookup from a UDDI compliant Registry. I've done this before and this does not require any run-time lookup of a web service's WSDL.

There is an additional benefit to this method as well. Have you ever gone through the process of defining a WSDL and Schema using best practices for web services interoperability, implemented a service using that WSDL and Schema, and then looked at the auto-generated WSDL? You may be surprised to find that the automatic generated WSDL may be in a majority of cases is not as clean or easy to follow and in some cases may indeed be wrong. The best practice for developing interoperable web services recommends following a contract-first approach. This requires that the "contract" i.e. the WSDL and the Schema to be something that is developed with a great deal of care given to interoperability. Since the automatic generation of WSDL is platform-specific, there is always the possibility of some platform-specific artifacts ending up in the contract documents, which is not what you intended to happen.

Q. What about those existing/legacy services that do a run time lookup? Won't those break?

The question that needs to be asked at this point is why these services are doing a run time lookup, is there value being added by this capability in this client, and are there alternatives that will enable the client to provide the same functionality without compromising security?

As an example take the case of a BEA Weblogic client. If you will look at the documentation that BEA provides on building a Dynamic client you will note that they provide two different approaches, one that uses a dynamic WSDL lookup and another that does not. The interesting thing about this is that the approach that uses the WSDL makes a run-time lookup of a Web Service's WSDL which will end up breaking if the ?WSDL functionality is turned off. But the alternative approach of building a dynamic client provides the same functionality without the run-time WSDL lookup.

From what I can see, from a functional perspective there is no difference between the two approaches and given that one of the things that you want to do when developing web services, or any software for that matter, is to minimize the number of external dependencies, I would choose the second option of NOT doing a run-time WSDL lookup in this particular case. What is regrettable in this case is that it appears that the default configuration in BEA's tooling is to use the run-time WSDL option (Or so I have been informed), which leads to issues when folks who choose the default options with their tools develop the clients.

Mitigating these information disclosure threats requires both developers and operational support folks to understand their shared responsibility for security. Developer's need to understand that security should be part of the software development lifecycle and is not something that is bolted on at the end or is 'thrown over the wall' for someone else to take care of. Operational folks need to understand that a layered defense in depth strategy is needed and that secure coding practices of developers are an essential component of any operational environment. In particular the mentality of "Firewalls and SSL will save us all" needs to change for all parties concerned.

del.icio.us Tags: information-disclosure,web-services,WSDL-Scanning

Technorati Tags: information-disclosure,web-services,WSDL-Scanning

Digital Identity World 2008 Recap

Anil John — Sat, 13 Sep 2008 20:43:32 GMT

Digital ID World 2008 is the first IdM conference that I've gone to as part of a team, and given the variety of breakout sessions we decided early on to use the divide and conquer approach based on our areas of interest and expertise.

The following are some highlights on some (not all) of the sessions that I attended and found to be interesting. As with a lot of conferences, there were some sessions that were pretty much disguised vendor pitches which I am not even going to bother with a mention.

Keynote - Identity Assurance: A Backbone For The Identity Marketplace
by Peter Alterman - GSA, Andrew Nash - PayPal, Frank Villavicencio - Citigroup

In some ways this was rehash of the panel on the same topic that was moderated by Mark Diodati at Burton Catalyst but with the addition of Peter Alterman of the GSA, who tends to add a certain amount of ...ah... flair to the conversation :-)

The intent of the Liberty Identity Assurance Framework (IAF) is to develop a framework that leverages the existing work that has been done by EAP, tScheme, US e-Auth etc. to generate an identity assurance standard that is technology agnostic but provides a consistent way of of defining identity credential policy and the process and policy rule set etc. The IAF consists of four parts (1) Assurance Levels (2) Assessment Criteria (3) Accreditation and Certification Model and (4) Business Rules. You can find out more about it on the IAF Section of the Liberty Alliance Web Site.

What interested me about the entire conversation was the leveraging of OMB M-04-04 and NIST 800-63 to define the assurance criteria but the drive to make a "Liberty Alliance IAF Assurance Token" (if you will) that will be certified to mean the same thing across federations. Mr. Alterman also noted, and I hope that I interpreted this correctly, that the intent from the GSA side would be to not re-invent the wheel but to adopt this IAF framework going forward. He spoke of current inter-federation work he is involved in between NIH and the InCommon Federation that is leveraging this.

During the Q&A session, I brought up the fact that this work is directly focused on AuthN but in general, access to resources is granted based on a variety of factors, only one of which is the strength and assurance of the authentication token. The response is that the Liberty work is deliberately focusing on the AuthN and considers AuthZ to be out-of-scope for their work.

Keynote Presentation: State Of The Industry
by Jamie Lewis - Burton Group

Enterprise IdM is the set of business processes, and a supporting infrastructure, that provides identity-based access control to systems and resources in accordance with established policies.

Business trends are driving integration across processes and folks are being asked to do more with less.

SaaS is gaining momentum
Many failures in IdM projects caused by a lack of doing homework and a belief in the silver bullet product etc.
People manage risk, not products.
IdM is a means and not an end; It is about enabling capabilities and not an end in itself.
The Identity Big Bang is around new ways of working, collaborating and communicating
Make every project an installment on the Architecture and scope the goals to around 3 years.
Always think about data linking and cleansing

That was the first half of the keynote, but the second half was something I found to be very fascinating and is based on work that Burton has been proposing around the idea of a "Relationship Layer for the Web"

AuthN and AuthZ are necessary but not sufficient

Centrism of any kind does NOT work

Lessons from social science on trust, reciprocity, reputation etc.

The future of identity is relationships

Difference between close and distant relationships; Able to make many observations in a close relationship, so able to get good identity information. Not so for distant relationships

A good relationship provides value to all parties. And it is not just about rights but also obligations

Values like privacy etc. require awareness of relationship context

Systems fail if they are not "relationship-aware"

Difference between Custodial, Contextual and Transactional identities.
-- Custodial Identity is directly maintained by an org and a person has a direct relationship with the org.
-- Contextual identity is something you get from another party but there are rules associated with how that identity can be used.
-- Transactional identity is just the limited amount of info that an RP (?) gets to complete a transaction e.g. Ability to buy alcohol requires a person to be over 18 (?) but in a transactional relationship, you would simply ask the question of "Is this person old enough to buy alcohol?" and the answer would come back as "Yes/No". Compare this to a question of "What is this person's age or birthday?" which releases a lot more info.

The last type of identity in effect requires the existence of what Burton Calls an "Identity Oracle" (See Bob Blakley's blog entries) that has a primary and trusted relationship with a user as well as with relying party and can stand behind (from a legal and liability perspective) the transactional identity statements that it makes.

I found this entire topic absolutely fascinating as this is so very relevant to a lot of the work that I do around information sharing across organizations that may or may not trust each other for a variety of (sometimes very valid) reasons. Will be actively tracking this area on an ongoing basis.

The Plot To Kill Identity
by Pamela Dingle - Nulli Secundus

I really enjoyed this session by Pamela on the disconnect that currently exists between the needs of the users, what is being asked of the application vendors and the lack of a common vocabulary to express our needs such that there is a change in the same old way of doing business.

Need for an effort to be consistent all the way at the RFP/RFI time

Need a common vocabulary when requesting capability from vendors

Start with: Provide and Rely support i.e. the ability to choose whether or not a product relies on external identity services or provides its own.

Pamela also had a great starting set of RFI type questions one can use.. I am hoping that she will post them on her blog.

One of the questions I brought up during the Q&A session was that if I bought in to the Kool-Aid of what she discussed during the presentation (and I do), what would it take to scale the conversation to a larger audience? Bob Blakley, who was also in the audience, chimed in and noted that if Pamela wrote up a white-paper on the topic, he would help her get it published and widely distributed as well.

I would also be very interested in expanding the scope of the sample RFI questions to be grouped by product/project category (and released under an open licence; Creative Commons?) so that folks like me can use them in our RFP/RFIs as well.

There were more sessions that I attended that were interesting such as the Concordia Workshop on "Bootstrapping Identity Protocols: A Look At Integrating OpenID, ID-WSF, WS-Trust And SAML", "Using An Identity Capable Platform To Enhance Cardspace Interactions" and more..

All in all, beyond the sessions themselves, the hall-way conversations and the connections made to be as valuable (or even more so) than just the sessions themselves. I know that I found and made connections with multiple folks who work in my community and am very much looking forward to future collaborations with them and others.

del.icio.us Tags: Identity-Management,DIDW2008

Technorati Tags: Identity-Management,DIDW2008