Burton Group Identity Blog

Catalyst Europe is Coming Up Fast!

Blogger: Bob Blakley

We hit the stage for Catalyst Europe on April 19.  If you haven't already made your plans to join us in Prague, we've got a little treat for you at the end of this post.

We're going to focus this year on the emerging identity architecture.  If you're looking, you can see this identity architecture around you already, in offerings from mainstream identity vendors like Microsoft and Oracle, but also in offerings from smaller firms like Gluu, Unbound ID, Radiant Logic, and others.

The elevator-pitch version of the story is this: licensed provisioning software packages compete in a market for identity management systems.  User-centric identity providers compete in a market for identity providers.  What enterprises need is neither a market for identity management systems nor a market for identity providers - what they need is a market for identities.

Federation technology, directory virtualization, and contextual access control can be combined to create a technical architecture on top of which this market for identities can emerge.  The market for identities has many advantages, but getting there will take time and it will take work.  We'll lay out the roadmap in Prague.

If (like me) you're a last-minute kinda person and you haven't registered yet, here's your reward for waiting: use the promo code "INSIDER" during registration, and you'll get your ticket for the discounted price of only 995 Euro.

Sign up today and we'll see you there!

SPML Is On Life Support ….

Blogger: Mark Diodati

But it (or something like it) is desperately needed.

 

At Burton Group, we closely watch emerging identity standards. In particular, we pay close attention to the development and adoption of the Service Provisioning Markup Language. We have hosted two interoperability events at our Catalyst conference. We issued our first research document on SPML in early 2006—coincident with the release of the SPML v2 standard. The publishing of our second document is imminent, and it is based upon some “hands-on” work with the standard, as well as ongoing discussions with vendors, end-user organizations, and OASIS Provisioning Service Technical Committee members (past and present).

 

The primary goal of SPML is provisioning without the use of proprietary connectors. The reality is that SPML is not currently viable for building useful, standards-based provisioning services because it is too complex and places too much of a performance burden on the connector. For example, the SPML Search capability is required for most viable provisioning services, and its support is infeasible due to complexity and performance concerns. I’ll talk more about these issues (including the Search capability) in my next blog.

 

The SPML standard—like all emerging standards—requires more work. More work is required to harmonize SPML with SAML. An optional “inetorgperson-like” user schema is required to promote greater SPML adoption (the OASIS Provisioning Services Technical Committee tried to create a standard user schema when developing SPML v2, but the members could not agree on one). A simpler “real world” search capability is needed, with a limitation on the number of attributes and filter expressions. The latter two requirements should be combined into a future “SPML Simple” profile.

 

Unfortunately, there appears to be little industry support for SPML enhancements. A vicious cycle exists. Few people are using the standard, so there’s less momentum to enhance it. The IdM vendors’ participation in the OASIS Provisioning Services Technical Committee has been minimal at best since the 2006 approval of the SPML v2 standard. The last meeting of the Committee was in early 2008. None of the major provisioning vendors have developed an SPML v2-conformant product. Many of the vendors who have created commercial SPML connectors tell us that they must create specific SPML implementations for each of the major provisioning products. An SPML reference implementation does not exist, but would surely help.

 

What is the future of standards-based provisioning?

 

SPML may prevail if the industry simplifies the standard and supports it in commercial products. It may be too late to pull it out of the fire, though. Another alternative is a “pull” model—LDAP-based directory services supported by virtual directories. For example, both salesforce.com and Google provide a pull capability via LDAP. The applications query existing enterprise directories for authentication and identity information. Many organizations express concern about exposing a directory (especially Active Directory) to cloud-based applications. Burton group believes that virtual directories can mitigate these concerns. It is worth noting that neither vendor supports SPML. Both salesforce.com and Google expose a relatively simple (compared to SPML) SOAP interface for provisioning. Another path to standards-based provisioning may be SAML.

 

My colleague Bob Blakely will be speaking more about standards-based provisioning in the IdPS Telebriefing “The Future of Identity Management is Pull”.

Identity Services: Tackling Authorization

Blogger: Kevin Kampman

At the end of 2009, the Identity Services Work Group (ISWG) found a formal home at the Kantara Initiative. Encouraged by its prior work products, and the interest and participation at Burton Group’s Birds of a Feather session at Catalyst San Diego earlier in the year, the group revised its charter and the group was approved by Kantara’s leadership committee.

 

The group anticipates that the Kantara Initiative will increase opportunities for participation and distribution of its results. Observers or participants do not have to be Kantara Initiative members, and there is no investment requirement to become involved, although participants must sign a Group Participation Agreement (GPA). Brett McDowell, Kantara Initiative Executive Director, indicates that the results of the effort will be “freely re-usable and will be advanced by an open, inclusive and democratic process.”

 

At this point, the Identity and Access Services (IAS) group has issued a call for leadership and participation. The first order of business is to continue building out the use cases for authorization. If you are interested in participating, contact Gavin Illingworth at gavin.illingworth@bmo.com or register at http://signup.kantarainitiative.org/.

The Identity Services Work Group: Coming of Age

Blogger: Kevin Kampman

The Identity Services Work Group (ISWG) has been successful identifying issues and approaches for identity management technology interoperability. This ad-hoc effort has been going on for several years and represents an international community of enterprise users and vendors. As an example of its activities, the ISWG produced an architecture and initial use case for authorization. Burton Group has published two documents summarizing these efforts (subscription required): The Challenge of Identity Services, and Identity Services Architecture: Working Toward Consensus.

In 2009, the ISWG participants recognized the need to formalize their activities. After surveying related groups and a discussion of options at Burton Group’s Catalyst conference, the decision was made to approach the Kantara Initiative. Gavin Illingworth (Bank of Montreal) led this effort, assisted by Jeff Broberg (CA) and John Tolbert (Boeing).

On December 2nd, the formation of the Identity and Access Services Work Group (IAS-WG) was voted on and approved. Among the benefits to the former ISWG and to the Kantara Initiative are alignment with and influence over related identity efforts, access to a broader and more global constituency, an open discussion of challenges and solutions, and facilitation of group activities.

The unique interaction between enterprise customers and product vendors at the ISWG was productive, and it is gratifying to see the effort move forward based on its initial success. Former ISWG participants and new members are welcome to participate, and can contact Gavin (gavin.illingworth@bmo.com) or the Kantara Initiative for more information.

RSA, VeriSign, Cloud, OTPs, and Token Necklaces

Blogger: Mark Diodati

Today, RSA and VeriSign announced a partnership where VeriSign can resell SecurID OTP tokens via its VIP managed authentication service. RSA can also resell the VIP authentication service.

The press release implies that the relationship between RSA and VeriSign has been co-operative and amicable. Don’t be fooled. In early 2005, VeriSign was the primary driver for the OATH industry group, expressly created to take on RSA’s “cash cow”–its SecurID OTP business. Since that time, VeriSign aggressively pursued RSA’s SecurID customers and competes against RSA in the consumer authentication space.

As applications move to the cloud (e.g., SaaS), it is essential that users are not required to carry more than one OTP to access SaaS applications from different providers. This scenario is very similar to what we’ve seen in the enterprise—the “token necklace”. Users carried multiple authenticators around their neck because the authentication domains did not speak to each other.  RSA and VeriSign launched managed authentication services (the aforementioned VIP service and RSA’s Go ID service) which can overcome the token necklace issue by enabling many organizations to leverage a single token for authentication. Now that RSA can resell the VIP service, is this the end (or more likely, the de-emphasis) of RSA’s Go ID service?

This agreement provides VeriSign with some powerful capabilities. The VIP service will now work with both VeriSign (OATH-based) and RSA SecurID tokens. It’s likely that customers can mix and match token types based upon their application support and price requirements. Because VeriSign can bundle SecurID into its managed service, I believe it got the better part of the deal.

RSA derives two benefits from the partnership. Presumably, RSA will sell more SecurID tokens. Also, RSA’s ability to resell the VeriSign managed service gives broader entry into the managed authentication services market and with it the ability to better address the emergence of cloud applications (which enables RSA to sell more tokens).

Over time, the OTP form factor of choice for cloud-based applications will be the software token installed on the user’s mobile phone. We discuss this in our research document “More, More, More: The Challenge of Extended Enterprise Authentication Mobility” (subscription required).

US Government Identity News

Blogger: Bob Blakley

9/9/9 was a day of announcements.  You’ve already undoubtedly heard about the 64GB iPod touch, and if you’ve also heard about the new Leica M9 you know what to get me for Christmas this year.

But the identity world had its own big news today; the news is that the US Government has teamed up with the OpenID Foundation, the Information Card Foundation, the Kantara Initiative, and InCommon in creating the Open Identity Initiative. 

This is a really big deal, for two reasons.

First, as a condition of playing with the government in this game, OIDF and ICF have had to address the longest-standing and most serious defect in the open identity ecosystem: the lack of a trust infrastructure.  “What’s a trust infrastructure”, I hear you cry...

When you receive an X.509 certificate from a PKI provider, you can go to the provider’s site and read its Certification Practice Statement.  This statement provides three critical pieces of information:

1. What the provider does to ensure that the person who sent you the certificate is who he says he is.
2. What the provider does to ensure that its own systems aren’t compromised in a way that would allow people to create fraudulent certificates or steal private keys.
3. What obligations the provider undertakes and what remedies it will provide to its customers (i.e. YOU) if it breaches those obligations.

There’s never been any equivalent of a Certification Practice Statement for open identity providers.  Today’s announcement changes that.  The Open Identity Initiative has created a Trust Framework Provider Adoption Process which will allow organizations to set themselves up as roots of trust for open identity.  Organizations which serve as trust roots will assess the practices and guarantees of identity providers, and they will establish registries of providers and “score” them against a set of identity assurance criteria aligned with the Liberty Alliance Identity Assurance Framework and the OMB M-04-04 and NIST SP 800-63 guidelines.

So, if a few serious organizations sign up to become Trust Framework Providers, we’ll finally have a trust infrastructure for open identity.

The second reason today’s announcement is a really big deal is that, after years of government attempts to create identities and assign them to citizens (via such bad ideas as the UK National ID scheme and the US REAL-ID act), a government has finally recognized that individuals already HAVE identities, and that it’s a better idea, for most purposes, to use these identities than to establish a new government bureaucracy to create new identities – especially if they’re identities people don’t want.

If this initiative succeeds, and I hope it does, it’s almost certain to be a much cheaper route to government consumption of reliable digital identities of citizens than something like REAL-ID would be.  And it will preserve consumer choice at the same time as encouraging innovation in commercial identity technology.

So three cheers for Vivek Kundra and the boards of the OpenID Foundation, the Information Card Foundation, the Kantara Initiative, and InCommon.  And while we’re at it, let’s not forget to congratulate OSIS and the Internet Identity Workshop, where many of the technologies behind today’s announcement were developed and more of the ideas were born, and the Liberty Alliance, whose work on the Identity Assurance Framework is the keystone of the trust infrastructure we are finally about to see.

Down with federated provisioning

Blogger: Ian Glazer

There's been a bit of recent blogging activity about federated provisioning and SPML.  Having worked on both federated provisioning and SPML in a past life, it warms my heart to see this discussion.  Jackson, quoting the CIO of Education Testing Services, Daniel Wakeman, restates the observation that SaaS providers are providing when it comes to federated identity management.  This "major shortcoming" leaves service subscribers to fend for themselves in managing user lifecycle events like on-boarding and off-boarding.  Not acceptable.

That got me thinking - there really ought not to be a concept of federated provisioning.  Provisioning an application in the data center must be the same as provisioning an application in the cloud.  However, in the course of the conversation between James, Jackson, and Mark, it seemed SaaS applications and in-house applications were different from a provisioning perspective.

SaaS applications may be harder to provision and de-provision than non-SaaS application, but that doesn't make them fundamentally different animals.  The point was made that SaaS apps lack a standards-based provisioning interface, an SPML interface.  The fact is the vast majority of applications, SaaS or not, lack a standards-based provisioning interface and this makes dealing with them very much the same.

Now there are two reasons that we don't hear the same short of clamor about provisioning non-SaaS applications as we do with SaaS applications:

• We've dealt with it so long that pain isn't as acute
• Provisioning vendors built an array of connectors, shifting the pain up a level, allowing companies to focus on the provisioning technology and not each and every application they want to provision

Provisioning vendors spent lots of time and money to build connectivity to traditional applications.  Lots.  And in doing so provided a bit of absolution for application vendors from their failing to provide a standards-based provisioning interface.  Having gone through all that pain and suffering, vendors are not eager to go through it again with SaaS applications, coding connectors to each one's different web service.  Customers aren't too keen on the idea either.

In providing SPML interfaces to their applications, SaaS vendors would do everyone a service.  Provisioning vendors could use their SPML connectors and not have to build to each SaaS application.  Customers wouldn't have to write custom code to different service interfaces.

You don't want that fired sales guy walking away with your customer list no more than you want him walking out the door with your pricing information.  To that end, there should be no reason why deprovsioning from an application like Salesforce.com is any harder than deprovisioning from LDAP.  Federated provisioning should not exist; there is only provisioning.

New Year’s Resolution: Let’s Talk More about SPML

Blogger: Mark Diodati

Jackson Shaw and James McGovern have been blogging recently about one of my favorite topics: Service Provisioning Markup Language (SPML).  I’d like to contribute to the discussion.  You can find Jackson’s blog entry from December 20 here, and James McGovern’s blog entry from January 5 here.

One thing that organizations using SPML should do is to secure the service from an authentication, authorization, and encryption perspective.  In most instances, because the number of SPML requestors and providers (this is terminology specific to SPML) are small, most organizations are opting to manually configure the requesting authority and the provisioning service provider with static passwords or certificate lists to establish trust between the provisioning services components.  These authentication techniques don’t provide authorization services in any meaningful sense.  A large SPML implementation requires authorization services to determine the rights of the requesting authority to manage the specific user on the respective provisioning service target.  In our opinion, the multi-tenancy (call it cloud-based if you like) use case is an example of a large SPML implementation – one must build the requisite authorization and authentication services to support the provisioning service.

SPML’s lack of authentication and authorization capabilities highlights the broader issues we see with the emergence of identity services.  An authorization service requires authentication services in order to have any utility whatsoever.  The authorization and authentication services may be consolidated (one big authorization and authentication service) or discrete (two separate services).  One example of a discrete authorization service is a XACML authorization service that leverages the user’s SiteMinder SMSESSION ticket for authentication.

As for federation and federated provisioning, the lack of provisioning capabilities remains an operational impediment.  Several years ago, a Liberty Alliance Technical Expert Group began working on a way to “harmonize” SPML and SAML.  While the services would remain separate “pipes”, the TEG was working on a way to harmonize the user attribute schema across the two services.

James’ blog entry discusses the inter-enterprise standardization of roles.  From talking to my colleague Kevin Kampman, there's been little if any traction to date.  It really highlights the fact that a role is a representation of responsibilities coupled to a relationship, and getting common agreement on this is problematic.

If you are interested in more detail, we published a research document on SPML.  The document discusses the v2 specification in depth, as well as the differences between the v2 specification and the v1 specification.  It also discusses the barriers to the ubiquitous use of SPML.  You can find the document at http://www.burtongroup.com/Client/Research/Document.aspx?cid=848 (client subscription required).

Can Applications Become Identity-Stateless

Blogger: Gerry Gebel

Over time, we evolve our thinking about different aspects of the identity management market by sharing thoughts internally at Burton Group within the IdPS team – evidenced by the way we discuss the importance of relationship management, which really came together earlier this summer. Another way to accelerate this process is to get out of the office and exchange ideas in person with peers and colleagues in the industry. This past week I had the chance to spend some time with my old friend Felix Gaehtgens and we talked a lot about identity management – but this was after we settled any arguments about Belgian chocolate, Cuban cigars, fine teas, Belgian beer, and politics. Well, maybe we didn’t settle anything but just argued some more…

One of the questions Felix and I were trying to answer was: can we just stop doing user provisioning? It costs a tremendous amount of money, time, and effort to buy and implement provisioning systems – is there another way to approach this? The root cause, of course, is that applications, operating systems, etc typically require a local identity and security context – and provisioning is the way the industry establishes that context by creating accounts and setting entitlements on the local system or platform. Even contemporary applications excessively embed IdM functionality, and identity data into business applications. We can excuse legacy application developers this offense, but why does the approach persist? For several years, the industry has promoted the use of shared infrastructure services for IdM functions – but only a moderate level of success has been achieved when compared to the potential. Maybe the industry needs to consider a different concept that explains the goal state better – we settled on “stateless” as a possibly better descriptor to use.

The idea came into clearer focus the next day when I was invited to join the folks from SURFnet for a session to brainstorm how they should change the SURFfederatie service to meet future demands of the higher education market in a changing world. I was fortunate enough to be joined by identity luminaries Eve Maler and Andre Durand in this effort and it was a great session. Based on conversation during a breakout meeting, I thought we should start suggesting that applications should be stateless, from an identity perspective. That is, application designers should start with the premise that no identity data is stored locally (there will be reasonable exceptions) and this information, data, and policies are resolved during the run time process. Applications that can go any time to an explicit identity service doesn't need to be provisioned; it just needs to be connected. Therefore, if you start with the premise that applications are identity-stateless, you need to consider what identity services are required for fulfillment. Many applications in use today do not perform authentication locally – this is quite common. If applications are truly identity-stateless, we can take it a lot further.

Eventually the conversation will get around to the composition and level of abstraction for the above mentioned identity services. I’ll leave that topic to my colleague Kevin Kampman, who will be providing the latest update next week at Catalyst in Prague.