I have always had a very Microsoft Windows centric environment in my house with all of the machines in the house joined to an Active Directory domain to provide management capabilities such as centralized login, software deployment, re-direction of My Documents folders to my NAS, and more.

Up until a couple of years ago, I even used to run a mail server at home.  Overkill, I know, but this was not a case of "need" as much as "just because I could" and since I don't do this professionally any more, a way to keep up with what is going on (and as strange as it may sound, I found it relaxing). But that stopped being fun when I simply could not keep up with the deluge of spam. That resulted in me outsourcing my email infrastructure to the Cloud via Google Apps for Domains.

Recently, I made a switch to using a Mac as my primary desktop as well as my travel laptop. The switch was driven by my kids getting getting new Macbook Pro laptops as replacements for their previous hand me down PC laptops. My wife has always had a Mac laptop from work but that had never impacted our home network except for her having the ability to use the home printer.

This, of course, has resulted in me running as fast as possible to catch up with them as they explore the capabilities of their laptops. The great thing for me has been the forced reunion with my Unix roots.  I used to run FreeBSD servers back in the day before I switched over to Linux (because it had more apps) to finally arrive in the Windows world.

For folks who are going thru this I would highly recommend the O'Reilly Mac OS X Snow Leopard: The Missing Manual and Switching to the Mac: The Missing Manual, Snow Leopard Edition, both by David Pogue.

What I have liked to date:

• Hardware fit, finish and usability touches
• Software installation and un-installation
• Keyboard short-cuts
• Trackpad gesture support
• Spotlight (Desktop Search)
• Multi-monitor support
• Power management
• Parental Controls
• Scripting for automation support
• Integration with my Netgear ReadyNAS
• Integration with Google Apps for Domains

What I would change:

• The seemingly blind, but ultimately misguided, belief in the security of the OS as demonstrated by the firewall being turned off by default even on the laptops

On the whole, the transition has been pretty smooth as I have found the same programs or close analogs on the Mac side that I have traditionally used on the Windows side.  In other places, I am using the Remote Desktop Client for the Mac, from Microsoft, to connect to my existing Windows Machines when I need them.

There has been a great deal of excitement about the US Federal Government's ICAM initiative that provides for the development of Trust Frameworks, and providers of same, that has resulted in the emergence of identity providers who can issue credentials to citizens that can be used to gain access to Government websites/applications/relying parties. In all of the discussions surrounding these efforts, the focus has been on leveraging existing OpenID, Information Card or other types of credentials issued by commercial or educational organizations to access Government resources.

But, is that all we want from our Government?

In this blog posting, I am going to consciously side-step the concept of the Government as an Identity Provider. In the United States at least, much more thoughtful people than I have discussed, debated and argued about the feasibility of this and I do not believe that I can add much value here. The general consensus to date seems to be that the value proposition around the concept of a "National Identity Card" has many challenges to overcome before it is seen as something that is viable in the US. Whether this is true or not, I leave to others to ponder.

But what about the US Government vouching for the attributes/claims of a person that they are already managing with our implicit or explicit permission?

My last blog post "The Future of Identity Management is...Now" spoke to the pull-based future of identity management:

• ...
• "The input to these decisions are based on information about the subject, information about the resource, environmental/contextual information, and more, that are often expressed as attributes/claims.
• These attributes/claims can reside in multiple authoritative sources where the authoritative-ness/relevance may be based on the closeness of a relationship that the keeper/data-steward of the source has with the subject."
• ...

There are certainly attributes/claims for which the US Government has the closest of relationship with its citizens and residents and as such remain the authoritative source:

• Citizenship - State Department
• Address Information - Postal Service
• Eligibility to Work in the US - Department of Homeland Security
• Eligibility to Drive - State Government DMVs
• More...

I may be wrong about which agency is responsible for what, but I hope you see my point. There are some fundamental attributes about a person, that in the US, that are managed through its life-cyle by the Government, whether Federal or State.

I firmly believe, as someone who has been involved in demonstrating the feasibility of pull based identity architectures for delivering the right information to the right person at the moment of need using current commercial technologies and standards, that we have reached a point in time where the combination of the maturity of approaches and technologies such as the Federal ICAM Backend Attribute Exchange or the Identity Meta-system technologies and the willingness of the Government to engage with the public in the area of identity, that it is time to have a discussion about this topic.

The questions are definitely NOT technical in nature but are more around need and interest, feasibility and value with a heavy infusion of privacy. Some initial questions to start the conversation rolling would be:

• What are a core set of attributes that can serve as a starting point for discussion?
• Who would find value in utilizing them? How is it any better than what they have in place right now?
• What are the privacy implications of specific attributes? How can they be mitigated (e.g. Ask if this person is old enough to buy alcohol vs. What is your birthday/age?
• Liability in case of mistakes
• How would the Government recoup some of the costs? We pay for passport renewals, we pay for driver's license renewals; don't expect this to come for free
• Much, much more....

I would be curious to find out if there is any interest in this topic and if so what your reactions are. If there is interest, and given that the next Internet Identity Workshop is for the first time going to be held on the East Coast (Washington DC) on September 9-10 with a focus on "Open Identity for Open Government", and given its un-conference nature, was going to propose this as a topic of discussion.

UPDATE: Ian Glazer, Research Director for Identity and Privacy at Gartner has agreed to tag team with me on this topic at IIW in DC. Ian's research and interests sit at the very important intersection of Identity and Privacy, and I think he will bring that much needed perspective to this conversation.

He also thought that the topic should be more correctly termed "Government's role as an Oracle" rather than as an Attribute Provider, and since I agree, that will more than likely end up being the topic

To see what is meant by an Identity Oracle and what it is NOT, read this and this blog posts by Bob Blakely

The Gartner/Burton Group conference has a very high signal to noise ratio and is one that I was fortunate to present at this year. I spoke in my role as the Technical Lead for DHS Science & Technology Directorate's Identity Management Testbed about how we are taking the Federal ICAM Backend Attribute Exchange Interface and Architecture Specification from Profile to Usage.

The biggest buzz in the Identity Management track, where I spent most of my time, was around the “pull” based architecture that Bob Blakley and the rest of the Burton crew have been writing and speaking about for a while as being the future of Identity Management. The key take-away’s for me on this topic are:

• We are moving to an era where dynamic, contextual, policy driven mechanisms are needed to make real time access control decisions at the moment of need.
• The policy driven nature of the decisions require that the decision making capability be externalized from systems/applications/services and not be embedded within and that policy be treated as a first class citizen.
• The input to these decisions are based on information about the subject, information about the resource, environmental/contextual information, and more, that are often expressed as attributes/claims.
• These attributes/claims can reside in multiple authoritative sources where the authoritative-ness/relevance may be based on the closeness of a relationship that the keeper/data-steward of the source has with the subject.
• The relevant attributes are retrieved (“pulled”) from the variety of sources at the moment when a subject needs to access a system and are not pre-provisioned into the system.
• Standards! Standards! Standards! All of the moving parts here (finding/correlating attributes, movement of attributes across organizational boundaries, decision control mechanisms etc.) needs to be using standards based interfaces and technologies.

Potential implementation technologies proposed include virtual directories as mechanisms that can consolidate and correlate across multiple sources of attributes, standards such as LDAP(S), SAML and SPML as the plumbing standards, and External Authorization Mangers (“XACMLoids”) as decision engines.

What was interesting and relevant to me is the the US Federal Government via the ICAM effort as well as the Homeland Security, Defense and other communities have embraced this viewpoint for a while and are putting into place both the infrastructure to support it at scale, and have working implementations in use.

In particular my presentation was about how we are working an information sharing effort between two organizations who need to collaborate and share information in the event of a natural or man-made disaster where there is no way we could pre-provision users since we won’t know who those users are until they try to access systems. Our end-to-end implementation architecture really reflects pretty much everything noted in the Burton vision of the future. Relevant bits from the abstract:

The Backend Attribute Exchange (BAE) Interface and Architecture Specifications define capabilities that provide for both the real time exchange of user attributes across federated domains using SAML and for the batch exchange of user attributes using SPML.

The DHS Science & Technology (S&T) Directorate in partnership with the DOD Defense Manpower Data Center (DMDC), profiled SAML v2.0 as part of a iterative proof of concept implementation. The lessons learned and the profiles were submitted to the Federal CIO Council’s Identity, Credentialing and Access Management (ICAM) Sub-Committee and are now part of the Federal Government's ICAM Roadmap as the standardized mechanism for Attribute Exchange across Government Agencies […]

This presentation will provide an overview of the BAE profiling effort, technical details regarding the choices made, vendor implementations, usage scenarios and discuss extensibility points that make this profile relevant to Commercial as well as Federal, State, Local and Tribal Government entities.

In our flow there is a clear separation of concerns between Authentication and Authorization and in the language of my community, the subject that is attempting to access the Relying Party application is an “Unanticipated User” i.e. a subject that is from outside that organization who has NOT been provisioned in the RP Application.

1. There is a organizational access control policy that is externalized from the application via the Externalized Authorization Manager (EAM) that is dynamic in nature (“Allow access to user if user is from organization X, has attributes Y and Z and the current environment status is Green”).
2. The subject is identified as being from outside the organization, is authenticated and an account is created in the system. The subject has no roles, rights or privileges within the system.
3. The EAM pulls the attributes that are needed from external (to organization) sources to execute the access control policy and based on a permit decision grants access to resources that are allowed by policy.

All of this, BTW, is taking place using existing standards such as SAML and XACML and technologies such as Virtual Directories, XML Security Gateways, Externalized Access Management solutions etc. This works now using existing technology and standards and gets us away from the often proprietary, connector-driven, provisioning-dependent architectures and moves us to something that works very well in a federated world.

To us this is not the future of Identity Management. This is Now!

My son has multiple food allergies, so dining out as a family is something we do not do on an ad-hoc basis but approach with a great deal of planning and care.  This becomes a bit more complex when we are traveling or on vacation.  Given that we have family in Western Canada, one of our favorite places to vacation is Banff National Park. The opportunity to go completely off-grid and to hike, bike, horse back ride and just enjoy the magnificent Canadian Rockies is something that we look forward to.

I don’t typically make a point of calling out places that we have patronized but this is an exception given that many families are in the same circumstances as mine when it comes to travel and food allergies. 

We had a great experience this summer (and for many years before) at the Rimrock Resort Hotel in Banff where the combination of Chef Guy St-Hilaire and the Food & Beverage Supervisor Mr. David Perry did an absolutely top notch job of addressing our concerns and coordinating the service that we received from any of the restaurants and from all the food service staff. And they did it in a friendly, personalized manner that made my son feel special and not different. He absolutely had a blast and we can’t ask for anything more than that.

If you are traveling to the Banff area, my recommendation would be to give them a call before you get there, ask to speak to either Guy or David and let them know your food allergy concerns. I would bet you that they will take as good care of you and/or your family as they did mine.

I had the opportunity earlier in the week to attend the 9th Symposium on Identity and Trust on the Internet (IDtrust 2010) which was held at NIST.

Given that a lot of the work that I am currently doing is centered around externalized, policy driven Authorization using Attribute Based Access Control (ABAC) and the profiling and deployment of Enterprise Attribute Services, I found a paper [PDF] and presentation [PDF] given by Ivonne Thomas from the Hasso-Plattner-Institue for IT-Systems Engineering to be very interesting.

As an aside, one of the best explanations on conveying what ABAC is all about, particularly to business owners, was given by a colleague who works for the DOD in this particular domain (Thanks Ken B).

“Consider if you will, the following two situations.

You are standing in line at the Grocery store and a little old lady in a walker comes up to you and demands your driver’s license and proof-of-insurance! You will be making a particular decision at that time. Now, consider if the same question was asked of you with red and blue lights blinking behind you and someone with a badge and a gun is knocking on your windshield asking for the same information.

We make these types of decisions all the time in our lives based on a real time evaluation of who is asking the question, what they want access to, and the context in which the question is being asked. ABAC is how we could do the same thing in the electronic world. Making a real-time access control decision based on attributes of the subject, the attributes of the resource and the attributes of the environment/context.”

I love this explanation and have shamelessly stolen and used it to great effect in multiple situations.

Coming back to the paper, given that Attributes are used to make these critical access control decisions, how does one judge the “trust-worthiness” and/or “authoritative-ness” of each attribute that are used to make the decision?  How could one convey these qualities related to attributes to a Relying Party so that it can make a nuanced access control decision?

On the authentication front, we have an existing body of work that can be leveraged such as the OMB E-Authentication Guidance M-04-04 [PDF] which defines the four Levels of Assurance (LOA) for the US Federal Government and the attendant NIST SP 800-63 [PDF] that defines the technologies that can be used to meet the requirements of M-04-04.  In particular, you have the ability to use SAML Authentication Context to convey the LOA statements in conformance with an identity assurance framework.

The paper, which I think has a misleading title, uses the Authentication Context approach as an example and defines an extension to the SAML 2.0 schema for what is termed by the Authors as an “Attribute Context” which can be applied to each Attribute value. The authors define the parts as:

• Attribute Context This data element holds the attribute context,  which is comprised of all additional information to the attribute value itself. This element is the upper container for all identity metadata.
• Attribute Data Source This data element indicates the source from which the attribute value was originally received and is part of the Attribute Context. This  can  be  for  example  another  identity  provider, some authority as a certificate authority or the user himself who entered the data.
• Verification  Context This data element holds the verification context, which comprises all information related to the verification of an identity attribute value. The Verification Context is one specific context within the Attribute Context.
• Verification Status This data element indicates the verification status of an identity attribute value, which should be one of “verified”, “not verified” or “unknown”. The verification status is part of the verification context.
• Verification Context Declaration The verification context declaration holds the verification process details.  Such a detail could for example be the method that has been used for verifying the correctness of the attribute.  Further extensions are possible and should be added here.  The verification context declaration besides the verification status make up the verification context.

I know of many folks who are working on the policy side of this question of how to judge the “authoritative-ness” of an Attribute under multiple topics such as “Attribute Assurance”, “Attribute Practice Statements”, “Authority Services” etc. etc.  But I have often thought about how one would go about conveying these types of assertions using current technology. This approach seems to provide an elegant approach for doing just that:

As you can see in the above example, the extensions proposed by the authors integrate nicely into a standard saml:AttributeStatement and convey the metadata about individual attributes to a Relying Party that can make a more nuanced access control decision.

I think this is a great beginning and would love to see the authors submit this to the OASIS Security Services (SAML) TC so that it can become part and parcel of the SAML 2.0 specification. I would also love to see a Profile come out of the OASIS SSTC that would define a consistent set of Verification Context Declarations.  In particular I believe that the concept of referencing “Governing Agreements” as defined in the current “SAML 2.0 Identity Assurance Profile, Version 1.0” (which is in public review) has applicability to this work as well.

At a meeting yesterday Judy Spencer, co-chair of the Federal CIO Council ICAMSC, briefed that NIST had recently re-released Special Publication 800-73 [PDF] to account for PIV-I Card Issuance.  These would be Smart Cards that can be issued by Non-Federal Issuer’s and can potentially be trusted by US Government Relying Parties.

The relevant bits are in Section 3.3 of NIST SP 800-73-3 (Quoting below so that I can easily reference them in the future):

3.3    Inclusion of Universally Unique IDentifiers (UUIDs)

As defined in [10], the presence of a Universally Unique IDentifier (UUID) conformant to the specification [11] is required in each identification card issued by Non-Federal Issuers, referred to as  “PIV Interoperable” (PIV-I) or “PIV Compatible” (PIV-C) cards.  The intent of [10] is to enable issuers to issue cards that are technically interoperable with Federal PIV Card readers and applications, and that may be trusted for particular purposes through a decision of the relying Federal Department or Agency.  Because the goal is interoperability of PIV-I and PIV-C with the Federal PIV System, the technical requirements for the inclusion of the UUID document are specified in this document. To include a UUID identifier on a PIV-I, PIV-C, or PIV Card, a credential issuer shall meet the following specifications for all relevant data objects present on an issued identification card.

1. If the card is a PIV-I or PIV-C card, the FASC-N in the CHUID shall have Agency Code equal to 9999, System Code equal to 9999, and Credential Number equal to 999999, indicating that a UUID is the primary credential identifier.  In this case, the FASC-N shall be omitted from the certificates and CMS-signed data objects. If the card is a PIV Card, the FASC-N in the CHUID shall be populated as described in Section 3.1.2, and the FASC-N shall be included in authentication certificates and CMS-signed data objects as required by FIPS 201.
2. The value of the GUID data element of the CHUID data object shall be a 16-byte binary representation of a valid UUID[11]. The UUID should be version 1, 4, or 5, as specified in [11], Section 4.1.3.
3. The same 16-byte binary representation of the UUID value shall be present as the value of an entryUUID attribute, as defined in [12], in any CMS-signed data object that is required to contain a pivFASC-N attribute on a PIV Card, i.e., in the fingerprint template and facial image data objects, if present.
4. The string representation of the same UUID value shall be present in the PIV Authentication Certificate and the Card Authentication Certificate, if present, in the subjectAltName extension encoded as a URI, as specified by [11], Section 3.

The option specified in this section supports the use of UUIDs by Non-Federal Issuers.  It also allows, but does not require, the use of UUIDs as optional data elements on PIV Cards.  PIV Cards must meet all requirements in FIPS 201 whether or not the UUID identifier option is used; in particular, the FASC-N identifier must be present in all PIV data objects as specified by FIPS 201 and its normative references.  PIV Cards that include UUIDs must include the UUIDs in all data objects described in (2) through (4).

At the IDManagement.gov site, you can also find a list of Credential Service Providers, cross-certified with the US Federal Bridge CA at Medium Hardware LOA (i.e. Meets the requirement that FIPS 140 Level 2 validated cryptographic modules are used for cryptographic operations as well as for the protection of trusted public keys), who have the ability to issue PIV-I Credentials.

To be conformant to SPML v2 means that the SPML interface (Provisioning Service Provider / PSP) MUST:

• Support the set of Core operations
• a discovery operation {listTargets} on the provider
• basic operations {add, lookup, modify, delete} that apply to objects on a target
• Supports basic operations for every schema entity that a target supports
• Supports modal mechanisms for asynchronous operations

There are additional “Standard” operations described in the OASIS SPML v2 Specification [Zip]. The clear thing to keep in mind is that each operations adds a data management burden onto the provider, so the choice of whether or not to implement them should be considered very carefully.

From the perspective of deployment topologies, the PSP could be deployed separately from the Target or could very well be integrated tightly with the Target e.g. an SPML compliant web service interface on a target system.

One of the frustrating items for me when enquiring about SPML support in products has been the lack of clarity and visibility around exactly what has been implemented. All too often, vendors seem to have cherry picked a chosen set of operations (whether from the Core or from the Standard list) and used that to claim SPML support. I would be very curious to see if anyone can claim full SPML v2 compliance.

A particular use case for SPML that I am currently working on has to deal with the “batch” movement of attributes from multiple systems to a central repository. The typical flow is as follows:

• Per organizational policy & relationship to user, attributes are assigned in their home organization and/or business unit (Org A / Org B / …)
• Org A must move those users and/or their attributes to a central repository (Repository X) on a regular basis
• Repository X acts as the authoritative source of attributes of users from multiple organizations / business units and can provide those attributes to authenticated and authorized entities in a real-time request/response and in a synch-take-offline-use modes.

Some points to keep in mind are:

• Org A / B / … may have, and all too often do, have their own existing identity and provisioning systems as well as associated governance processes in place.
• The organizations and the repository may or may not be under the same sphere of control and as such cannot mandate the use of the same piece of provisioning software and associated connectors on both ends of the divide.
• The systems where the organizations store the attributes of their users may not necessarily be directory based systems.
• The Repository may or may not be directory based system.
• Identity / Trust / Security are, as you may imagine, rather important in these types of transactions.

To meet these needs, we are currently profiling SPML to support the Core SPML Operations as well as the optional “BATCH” capability.  The “ASYNC” capability is something that we are more than likely going to support as well as it provides a mechanism for the provider to advertise support for asynchronous operations rather than have a request for an asynch operation fail on a requester with an error “status=’failed’” and “error=’unsupportedExecutionMode’”.

Keep in mind that the end result will satisfy more than just the one use case that I noted above. In fact, it satisfies many other use cases that we have that deal with both LACS and PACS scenarios. In addition, the profile will also bring in the pieces that are noted as out of scope in the SPML standard i.e. the Profiling of the Security protocols that are used to assure the integrity, confidentiality and trust of these exchanges. Fortunately, we can leverage some of previous work we have done in this space for that aspect.

Mark Diodati at the Burton Group kicked off this conversation in his blog post "SPML Is On Life Support..." Other folks, notably Nishant Kaushik ("SPML Under the Spotlight Again?"), Ingrid Melve ("Provisioning, will SPML emerge?") and Jeff Bohren ("Whither SPML or wither SPML?") bring additional perspectives to this conversation. There is also some chatter in the Twitter-verse around this topic as well.

As someone who has been involved in both the standards process as well as end user implementation, I have a semi-jaded perspective to offer on what it takes for vendors to implement interfaces that are standards based in their tooling/products. First of all, let it be clearly understood that Standards are beautiful things (and there are many of them) but a Standard without vendor tooling support is nothing more than shelf-ware. So in the case of Standards Based Provisioning, in order to get that tooling support, multiple things need to happen:

• First and foremost, do NOT let a vendor drive your architecture! User organizations need to break out the "vicious cycle" that exists by first realizing that there are choices beyond the proprietary connectors that are being peddled by vendors, and secondly by stepping up and defining provisioning architectures in a manner that prioritizes open interfaces, minimizes custom connectors and promotes diversity of vendor choice.  Map vendor technology into your architecture and not the other way around, because if you start from what a vendor's product gives you, you will always be limited by that vendor's vision, choices and motivations.
• Bring your use cases and pain points to the Standards development process and invest the time and effort (Yes, this is often painful and time consuming!) to incorporate your needs into the base standard itself. I am finding that often the Technical Committees in Standards Organizations are proposed and driven by vendors and not end users. But in cases where there is a good balance between end users and vendors, the Standard reflects the needs of real people (The Security Services/SAML TC at OASIS often comes to mind as a good example).
• Organizations need to incorporate the need for open standards into their product acquisition process. This needs to go beyond "Product X will support SPML" to explicit use cases as to which portions of the standard are important and relevant. Prototype what you need and be prepared to ask tough, detailed questions and ask for conformance tests against a profile of the Standard.
• Be prepared to actively work with vendors who treat you like an intelligent, strategic partner and are willing to invest their time in understanding your business needs and motivations. These are the folks who see the strategic value and business opportunities in supporting open interfaces and standards, realize they can turn and burn quicker than the competition, and compete on how fast they can innovate and on customer satisfaction versus depending on product lock-in.  They are out there, and it is incumbent upon organizations to drive the conversation with those folks.

Moving on, let me reiterate the comments that I made on Mark's blog posting:

"The concern with exposing LDAP/AD across organizational boundaries is real and may not be resolved at the technology level. Applying an existing cross-cutting security infrastructure to a SOAP binding (to SPML) is a proven and understood mechanism which is more acceptable to risk averse organizations.

I would also add two additional points:

1. More support for the XSD portion of SPML vs. DSML in vendor tooling. There are a LOT of authoritative sources of information that are simply NOT directories.
2. There needs to be the the analog of SAML metadata in the SPML world (Or a profile of SAML metadata that can be used with SPML) to bootstrap the discovery of capabilities. The "listTargets" operation is simply not enough."

While I do resonate with the "pull" model interfaces noted by Mark in his posting, I do believe that exposing LDAP(S)/AD Interfaces either directly of via Virtual Directories outside organizational boundaries is a non-starter for many organizations.

At the same time I believe there exists options in the current state of technology to provide a hybrid approach that can incorporate both the pull model as well as provide the application of cross-cutting security infrastructure into the mix. The architecture that we are currently using incorporates a combination of both Virtual/Meta Directory capabilities as well as an XML Security Gateway to provide policy enforcement (security and more) when exposed to the outside.

I will also reiterate that there needs to be more support for the XSD portion of SPML vs. DSML. A lot of the authoritative sources of user information that I am dealing with are simply not found in directory services but in other sources such as relational databases, custom web services and sometimes proprietary formats in addition to LDAP/AD.

I hope to post some the use cases for standards based provisioning as well as the details of some of the profiling that we are doing on SPML to satisfy those use cases in future blog posts. Looking forward to further conversations around this topic.

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:

1. Is this a known problem, or is this being caused by some oversight/mistake on my part (would not be the first time)?
2. 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.

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.