Burton Group Identity Blog

Where is HR?

Blogger: Kevin Kampman

Last week I accepted a speaking engagement on identity management with an uncommon audience: Human Resources (HR). I attended the Ohio Valley Chapter meeting of the International Association for Human Resource Information Management (IHRIM) in northern Kentucky. It is a rare event when someone from HR attends one of my tutorials or speaking sessions, and so it was intriguing to me to find a full audience of HR folks.

In preparation for the event, I contacted an HR director I am friends with and asked her what keeps HR people up at night. Her answer, including things like employee retention, competitive offerings, youth vs. experience, among others, did not have anything to do with identity management. So, I felt comfortable coming up with a list of IdM topics that I feel are critical to today’s HR organizations. The list includes

• Identity verification

• Roles and responsibilities

• Identity governance

• Identity audit

• Federation

Each of these topics has dependencies on information common to all biological assets in an organization (at the human level), particularly where current and accurate information about these people is required. This cuts across employees, contractors, partners, suppliers, anyone with an internal business relationship with the organization. These boundaries are much broader than the typical HR perspective.

The perceived lack of participation with identity management projects is a potential vulnerability to HR, in that IdM initiatives will move forward regardless of their involvement. This is not a good thing for HR, as HR runs the risk of marginalization if they are not seen as an essential contributor to the overall effort. This was my main theme for the discussion, and I expected to either be laughed off of the stage or acknowledged for my perceptiveness. Fortunately, there was acknowledgment that this risk is recognized and that HR is wants to come on board in the five topic areas we discussed.

To underscore the importance of IdM to HR, my co-presenter at the event, Carey Ellinghaus, a manager involved with HR transformation with The Hackett Group, provided a functional overview of IdM, primarily provisioning, and highlighted that top-performing organizations have engaged with HR to achieve both efficiency and effectiveness in IdM related activities. At the very least, our presentations represent areas that should cause discomfort, if not the loss of sleep, to forward thinking HR management. It is about time that my audiences include HR, in addition to IT, risk, and security.

A Call for Participation: The Next User-centric Interop

Blogger: Gerry Gebel

Planning for the next user-centric interoperability demonstration, to be hosted at Burton Group's Catalyst conference in Barcelona on October 23, has commenced and you are invited to participate. We are seeking developers of identity agent, identity provider, or relying party components to join us in the scoping, testing, and delivery of this project to further advance interoperability between user-centric identity systems. Others who are not purveyors of software systems, but want to actively participate are also welcome. The most recent interop demonstration, summarized here, accomplished a great deal - but also highlighted areas that needed further attention.

Process: We'll hammer out details on weekly conference calls and through a dedicated email list. Testing will occur over the Internet as soon as scenarios are solidified and participants have code ready.

Next steps: Input on scenarios remains open until this Wednesday, Aug 22. Contact me now if you are interested!

Some Predicted OpenID Weaknesses

Blogger: Bob Blakley

At Catalyst North America in San Francisco, I noted in my “New-School Identity Systems” talk that OpenID does not define the relationship between usernames and the names of the OpenID servers which authenticate the owners of those usernames.  I went on to predict that this would cause security problems.

A number of participants came up to me after the presentation and assured me that I was wrong, and that the lack of a defined set of trust anchor names and a defined set of rules for which portions of the user namespace each trust anchor was responsible for doesn’t create security issues with OpenID.

They were wrong and I was right; Eugene and Vlad Tsyrklevitch give details of the attacks I predicted in this paper from Black Hat 2007.  Their “Step 2” and “Step 4” attacks are precisely the sorts of things I’ve been expecting to see.  Thanks to Pamela Dingle for pointing me to the text of the paper, which I’d heard of but not seen until this morning.  There’s an accompanying presentation here.

Out of Context

Blogger: Bob Blakley

One of our readers has pointed out, correctly, that the iPhone entry below is out of context and doesn’t seem to have anything to do with Identity and Privacy.  I should have started by saying that Burton Group will shortly be hosting a TeleBriefing on “iPhones in the Enterprise” for our customers on 28 and 29 August; all of the participants (including me) have been asked to post our views on our respective service blogs in advance of the event to give people an idea of the range of opinions they may hear on the call.  You can read my SRMS colleagues’ rather different perspectives on the iPhone here and here.

Ready for Prime Time

Blogger: Bob Blakley

“The iPhone isn’t suitable for enterprise use.”

How many times have you heard this old chestnut?  It was only two years ago that the Blackberry wasn’t suitable for government or critical infrastructure use.  Palm Pilots were unsuitable for enterprise use too; remember when CIOs were talking about banning their use?   And cell phones?

Two of the most popular arguments against use of the iPhone in corporate environments are just nonsense:.

1. It’s insecure.  Yep.  So is everything else you’re using in the enterprise, including your much-dumber-than-i-Phone with a digital camera built into it.  Until you ban removable media and wireless access, stop complaining.
2. It doesn’t continuously update email via a push protocol.  Yep.  Get a prescription for Ritalin.  If you need something right now – check it out!  The iPhone has a keyboard!  CALL!

But it’s the third argument that’s the really important one: “The iPhone doesn’t integrate with my enterprise protocols.”  Like the other two objections, this one is accurate. Unlike the blackberry, the iPhone doesn’t slice your enterprise open, pull its guts out over the air, and hook them up to a little colostomy bag in your pocket.

This is the most important argument in favor of adopting the iPhone.

Your enterprise is a lot like a nuclear missile base; it’s a collection of silos filled with expensive, dangerous, decaying equipment built by a previous generation to respond to requirements different from those of today.  Most of your enterprise’s software is fundamentally incompatible with the Internet and other modern infrastructures.  It’s inflexible and it locks you into buying more software and services from vendors who innovate slowly.

The truth is, the critics have it backwards: it’s not that the iPhone is unsuitable for enterprise use – it’s that your enterprise is unsuitable for iPhone use.

If your enterprise already ran all its business on Web 2.0 protocols, assumed that the network is the system and that the browser is the operating system, and used Software-As-A-Service applications, you would pick up the iPhone and say “of COURSE this is the smartphone we should use.  It’s functionally exactly the same as our existing platform – but much smaller, much cheaper, and much more convenient for travelers.  It also makes phone calls without having to resort to Skype. And it connects to the web even when there’s no WiFi.  Brilliant!”

That’s the future you’re headed toward anyway.  Steve Jobs just saw it before you did.  He also knew that if your company doesn’t already get this, it’s almost certainly organized like Stalinist Russia, and won’t be able to make the necessary changes top-down.  But that’s OK, because (like its predecessors the cell phone, the PDA, and the laptop) it won’t be introduced into enterprises by management.  It will infiltrate the enterprise through the individual users, and it will be unstoppable.

Here’s my advice to CIOs, software architects, and security professionals: get an iPhone and use it.  Take it on a trip and leave your laptop at home.  This IS the future.  If you do not have an iPhone, you cannot and will not understand the future.  You need one of these to do your job.  Not your job as a telephone and web user – your job as one of the people who takes the enterprise into the future.

If you use an iPhone, you’ll learn that things which live in your house or your pocket are small, expensive, slow, and administered by amateurs.  Things that live in the cloud are big, fast, cheap, and administered by professionals.  You’ll learn that it’s much better for you if you let someone else install applications on their servers instead of making you install them on your tiny little machine.  You’ll learn that patching works much better if you do it on 5 servers than if you do it on 50,000 laptops (and don’t do it on the other 10,000).  You’ll learn that if the only thing two applications have to share is the presentation layer, they’ll conflict a lot less than if they have to share memory, ports, interrupts, disk, the registry, drivers, and so on.  You’ll learn that if you pay for actual capacity consumed rather than peak capacity, you can get a better deal.  In short, you’ll learn what terms like “Web 2.0” and “Web native” really mean.

If, on the other hand, your organization bans iPhones, it will fall behind its competitors who embrace them.  And if you don’t use one, you’ll wake up in two years like Rip Van Winkle and wonder how the world could have changed so much while you slumbered.

Are All Research Firms the Same?

Blogger: Jamie Lewis

We interrupt this identity conversation for a brief interlude related to Burton Group’s overall business – IT research.

For those who don’t know, we launched a promotion a week or so ago called “Drop a Seat,” in which we offer to give new customers enterprise wide access to one of our services for what our competitors charge for a single seat. We’re doing this because we’re hearing from our current customers and prospects that they’re getting price increases from those competitors, and they like the convenience of our enterprise wide pricing model. We think we have a better deal for enterprises, and thus would like to encourage a comparison.

With the announcement, of course, came at least some attention, and I couldn’t help but notice this blog post by Michael Krigsman on ZDNet. He points to and quotes from this post on Catching Flack, a blog about public relations, as follows:

“Analyst firms that charge vendors for relationships cannot truly objectively comment on the industry. Period. They spend most of their time on the phone with their paying clients (and are the most familiar with their products). They give the lion’s share of their coverage to paying clients. The whole structure of the system is to reward people that pay them and either overlook or outright punish folks that do not.”

I’ll have to admit that when we get painted with this broad brush, it gets my hackles up.

A customer recently asked me about independence issues, in particular how we handle the vendor aspect of our business. My response was simple: we addressed it at the foundation, in our business model. While the quote may accurately describe the business model of some analyst firms, it does not describe ours.

In general, an analyst firm can serve the supply side, or the buy side. We based our business on serving the buy side. About 85 percent of our revenue comes from enterprise buyers of technology products, with the other 15 percent coming from a mix of system integrators and vendors. Our top ten customers (in revenue) last year were all enterprises. We routinely cover, talk to, and discuss with clients vendors that do not subscribe to our research or buy anything from us whatsoever. (For more about what we don't do, see this.)

This all brings to mind a focus group with enterprise clients we held not too long ago. We were testing messaging and positioning with the group, and one of the messages was, “Burton Group is truly vendor-independent, and provides completely unbiased research.”

One respondent reacted negatively, saying, essentially, that all research firms say that, and thus it really wasn’t a good message. He followed that up by saying “but with you guys, it happens to be true.” That made me smile because it reflects the paradox. People tend not to believe such statements, for the very reasons that Michael Krigsman points out. But when customers get a chance to see our work, they see the proof in our pudding. So, when my hackles get up about such things, I simply remind myself that our customers know where our loyalties lie. And that’s why we're doing this promotion, to give more people a chance to see that we mean what we say.

Meta Madness

Blogger: Bob Blakley

Paul Madsen, commenting on my recent post regarding the Catalyst user-centric identity interop, argues that the event didn’t demonstrate the existence of a metasystem.  Robin Wilton agrees with him, as does Gerald Buechelt, who adds his criterion for what would constitute a metasystem:

“Even though there have been a number of different products and projects that successfully worked together, this technology is a far cry from being an identity meta-system. Multiple-protocol interop on the wire would be a true metasystem, and is a goal that various systems -- Liberty, OpenID, and Windows CardSpace included -- would need to work on together. Concordia is (probably more than) a first step towards this goal.”

Even if it were true that there was only one protocol demonstrated on the wire at the Catalyst interop event (which it is not; for example, a variety of different protocols were used to authenticate Identity Selectors to IDPs), I reject the assertion that you can’t have a metasystem without protocol diversity.

It was not a longing for different bitstreams on the wire which gave rise to the desire for an identity metasystem – it was a real honest-to-God human need: “I want to be able to visit different sites without having to create a new account at every site, and I want to do this in a way which doesn’t involve publishing everything about myself to everybody in the world”.

Meeting this need required the identity community to invent at least one set of protocols which enabled different identity systems (not “protocols”) to work together to allow users to carry their identity information around with them.

The fact that it ties multiple systems together is why it’s called a meta-system.  Notice that it’s not called a “meta-protocol”.

At the Catalyst interop event we saw users exporting managed cards from different Identity Provider systems into the same Identity Selector system.  We saw users using cards from the same Identity Provider system with different Relying Party systems.   We saw users authenticating to different Identity Provider Systems with the same (OpenID) credential.  We saw several configurations of these components working together with no Microsoft CardSpace components involved at all.

If the Liberty community and the WS-* community want to keep arguing with one another about whose protocols need to be in the mix before we call that mix a metasystem, I suppose there’s nothing that can stop them from doing that.  But the argument doesn’t help actual people or actual businesses get any interesting work done.

The participants in the Catalyst interop did help actual people and actual businesses get interesting work done.  That’s why OSIS is organizing more interops in the future; bringing Liberty-compliant components to these events and working with the other participants to make them interoperate with everyone else’s technologies would be much more useful than whining about how many protocols must dance on the head of a pin before we’re allowed to call it a meta-pin.

Incidentally, as both Gerald and Jeff Bohren note, the Catalyst interop was the second such event OSIS has organized.  I mentioned the first – held at IIW 2007a – in my initial posting.  I participated in the IIW inteorp and did not summarize it here only because Dale Olds has already posted an extensive and excellent writeup of the event.

Recapping the Catalyst user-centric interop

Blogger: Bob Blakley

The Burton Group hosted a User-Centric Identity Interop at the Catalyst Conference in San Francisco during the week of 23 - 29 June 2007; a public demo session was held on the evening of Wednesday 27 June to showcase the accomplishments of the participants in this event.

The interop event was a milestone in the maturation of user-centric identity technology.  Prior to the event, there were some specifications, one commercial product, and a number of open-source projects.  After the event, it can accurately be said that there is a running identity metasystem.  This identity metasystem is not grown up yet, and it still suffers from a number of issues.  But a lot of issues which used to exist have been fixed as a result of the efforts of the interop participants leading up to the event, and many more issues which were previously unknown have been identified and are being worked.  Many gaps in the user-centric identity and information card documentation have been identified and some have already been filled.  Microsoft's Open Specification Promise documentation set has been augmented with new material essential for smooth multi-vendor (or multi-project) interoperability.

The interop participants accomplished in two months of concentrated effort what it would probably have taken them a year to do working independently without the looming deadline provided by the Catalyst demo.  While it is still fair to say that user-centric identity technology is in its infancy, if progress continues at this rate the technology should be ready for enterprise adoption within a year.  The interop participants, recognizing the accelerant effect the Catalyst event has had on development of their technologies and products, are planning a series of future public interop events, some at Burton Group events and some elsewhere, to maintain the momentum they have built by participating in the Catalyst event.

PARTICIPANTS

24 organizations and individuals participated in the interop event; in alphabetical order they were: the Bandit project, BMC Software, Ian Brown, CA, FuGen Solutions, the Higgins project, IBM, Internet2, Microsoft, NetMesh, the Pamela Project, Oracle, Ping Identity, Sxip Identity, Verisign, WSO2, and XMLDAP.org.  This list includes for-profit corporations, open-source projects, and individuals.

The user-centric identity architecture includes three types of components: Identity Selectors (which allow users to select information cards and thus control which  claims are distributed to other parties), Relying Parties or RPs (which consume and rely upon claims to grant access and authority to users), and Identity Providers or IDPs (which manage user identity information and distribute it to RPs).

The participants brought 7 Identity Selectors to the interop event:

• 3 Higgins selectors

• Ian Brown's Safari plugin selector

• the Microsoft Windows Cardspace selector

• an early version of an upcoming version of the Microsoft Windows CardSpace selector

• the XMLDAP.org selector.

12 Identity Providers were tested during the interop event; again in alphabetical order, these were:

• Bandit Wag IDP

• FuGen's Test IDP

• the Higgins IDP

• IBM IDP

• the Internet2 Shibboleth IDP

• Kim Cameron's Identityblog HumanPresent IDP

• Microsoft Age STS IDP

• Microsoft's Windows Live Labs IDP

• the Ping Identity SignOn.com IDP

• the Verisign IDP

• the WSO2 IDP

• the XMLDAP IDP

25 Relying Parties were tested during the interop event; these were:

• 2 Bandit RPs

• the BMC RP

• the CA RP

• the FuGen Social Photos RP

• the Higgins RP

• the IBM RP

• the Internet2/University of Washington RP

• 2 Kim Cameron Identityblog RPs

• 2 Windows Live Labs RPs

• the Microsoft Age STS RP

• the Microsoft Fabrikam Friends RP

• the NetMesh RP

• 2 Pamela project RPs (one for Joomla, one for Wordpress)

• the Oracle RP

• the Ping Identity RP

• the Sxip Access RP

• the Verisign RP

• 2 WSO2 RPs

• the XMLDAP RP

• the CardSpaceDemos.com FriendsWithCards RP

RESULTS

The interop clearly showed that Microsoft's decision to open the information card specifications, combined with the identity community's enthusiasm for user-centric identity technologies, has resulted in a truly open environment with lots of innovation and a variety of commercial and open-source providers.

Two scenarios were tested:

1. Identity Selector imports managed information card from Identity Provider

2. Identity Selector logs user in to Relying Party using information card

    2a. using a self-issued information card
    2b. using a managed information card obtained from an IDP via scenario 1

Some Relying Party sites implemented customized content or behavior which was triggered based on claims generated by IDPs and consumed by RPs.

Many combinations of Identity Selector, Identity Provider, and Relying Party were tested - exact statistics can't be compiled because record-keeping during the event was not completely systematic.  Most tested combinations worked successfully in both scenarios.

Many issues were identified during the two months leading up to the Catalyst interop event, and most of them were fixed.  Vendors and open-source projects worked hard and they worked well together. 

Most of the issues identified arose from the usual sources: underspecification of namespaces, schemas, required and optional protocol elements, algorithms, and encodings; the next section ("ISSUES") enumerates the most important of these issues. Given the relative youth of the specifications and the explicit WS-* philosophy of trading off in favor of extensibility and flexibility and against completeness of specification, the existence of these issues is not surprising.  However it's also important to note that most of these issues will be easy to fix via profiles and additional specification detail. 

A few more serious issues arose also.  It became clear during the preparation for the interop that the trust semantics of IDP assertions are not yet firmly established; RPs need to be able to know what to expect when they consume an assertion from a new IDP, and this will not be possible until rules of trust are written down.  Interactions between users and RPs is also not yet sufficiently standardized.  Users who visit multiple RPs will need to be able to understand the icons they see on RP screens, and to understand in advance what behaviors to expect when they select those icons.  Some RPs require the use of encryption technology which is encumbered by international deployment restrictions.  Finally, it is not clear how the namespace of claims communicated from IDPs to RPs should be organized and governed.

ISSUES

Claim validation

• It became clear during the run-up to the interop that no standard set of token and claim validation procedures had been defined for RPs.

• Matching rule issues caused some failures (for example, is a URL with an appended "/" the same as or different from the same URL without the "/"?)

Claims and claim namespaces

• Some RPs rejected claims because they did not recognize the claim namespace generated by the IDP.

• Some RPs rejected claims because of case-sensitivity issues.

• The handling of claims with multivalued attributes appears not to be fully specified

• The semantics of an IDP issuing a claim are not clear; in particular it is not clear whether creation of a signed token containing a claim constitutes a statement by the IDP that it believes the claim is accurate.

Required and supported claims

• Some RPs required an exact match of required claims and presented claims; other RPs matched if required claims were a subset of presented claims.

• Some IDPs generated tokens with claims not requested by the RP; the consensus was that IDPs should not generate claims which do not appear in the RP's list of required or optional claims, because of privacy concerns.

Card Acquisition

• Card creation varies from IDP to IDP, and is in many cases primitive from a human-factors point of view.

• Procedures for importing cards are also not standard and are in some cases complicated or confusing.

Encoding

• SAML token version requirements are underspecified; IDPs and RPs need to be able to agree on the supported token versions.

• Base-64 encoding issues caused some failures due to incompatible assumptions about where line breaks may legally occur.

• Some RPs rejected claims because of ambiguities in what token information was to be included in the scope of hashes in signed tokens.

• Some RPs encountered issues with XML canonicalization of tokens.  Use of a standard canonicalization library may be desirable.

• Some issues were encountered with how plaintext data was padded prior to encryption.

• SOAP versioning (1.1 vs. 1.2) caused compatibility issues.

Certificates and Keys

• Some RPs required installation of a certificate on the selector machine.

• Certificate path validation is handled in a variety of ways by RPs; some RPs experience serious performance problems due to path validation.

• Introduction behavior is not well-specified; when an RP encounters a token from a previously unseen IDP which is not in an administered trust list, no standard behavior is defined.  Most RP failure modes provide little information to an administrator who might want to add the IDP to a trust list.

• Using EV Certificates requires complicated configuration.

Encryption algorithm support (and export restrictions)

• Some RPs could not decrypt tokens because they lacked support for the encryption algorithm used; furthermore, since the failure resulted from inability to  use 256-bit AES encryption, which is subject to US export controls and other international deployment and use restrictions, this problem may not be straightforward to fix.

Time

• Some RPs rejected assertions because of issues with synchronizing clocks between IDPs and RPs.

• When self-issued cards are used, time synchronization between the client machine running the Identity Selector and the RP server can cause failures.  Since client machines are less carefully administered than IDP and RP servers, this may prove to be a difficult issue.

Presentation

• Neither selector behavior nor RP behavior is standardized; it is not straightforward for users to know what to expect when using information cards with different selectors, or with the same selector but a variety of RPs.

• It was observed that some RPs are using different approaches to detecting and triggering identity selectors; this caused some failures.

• Some RPs exhibited different behavior on first visit (required registration of some sort) versus subsequent visits.

MOVING FORWARD

OSIS, a working group of Identity Commons, is already working on future interop events; the Burton Group and many of the interop participants working to host another interop event at the European Catalyst conference in October in Barcelona.

OSIS is also considering a number of other initiatives which should improve interoperability and usability of user-centric identity technology.  These include claim schema standardization, documentation of user-centric identity, OpenID, and information card best practices for Identity Selectors, Identity Providers, and Relying Parties, test suites for user-centric identity components, and interoperability profiles for user-centric identity components.

Active discussion of interoperability issues continues on the OSIS mailing list.

THANKS

Finally, a number of organizations and individuals deserve special thanks for their part in the Interop event.  Oracle contributed the monitors which were used to demo the technology to Catalyst attendees.

Johannes Ernst and NetMesh contributed the Wiki which was used to plan and administer the interop event.

Mike Jones of Microsoft not only devoted significant amounts of his time to the interop event but also moved heaven and earth at Microsoft to ensure that all the intellectual property needed to make the interop possible was included in the Open Specification Promise document set.  Microsoft also sponsored both the network and the catering for the interop event.

Pamela Dingle of Nulli Secundus and the Pamela Project devoted a significant amount of time to defining the interop scenarios and also helped organize the IIW interop which paved the way for the Catalyst event.

Dale Olds of the Bandit project sponsored the interop event; he also designed the illustrated brochure  which advertised it to Catalyst participants (a lot of work) and paid for the printing of the brochure.  Finally, Dale collaborated with Pamela on the organization of the IIW interop event.

Ping Identity sponsored a much-needed after-party for interop participants.  IBM, courtesy of Tony Nadalin, co-sponsored this party, as did we.