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!

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).

Will the “real” federated provisioning please stand up?

Blogger: Ian Glazer

Nishant has commented on my post about federated provisioning.  He has provided two different examples of federated provisioning.  One of these, the advanced provisioning example, involves a company who manages its employees’ access to a service provider service via provisioning.  In this case, Nishant agrees with me that provisioning of this sort is no different than provisioning the UNIX box down the hall.

But it is Nishant’s second example, the just-in-time provisioning example, which is a bit tougher.  In this case, the enterprise and its service provider have a federation in place.  Using SAML-based authentication, a new user attempts to access the service provider’s service.  The idea (hope?) is that the service provider recognizes the new user request, provisions the user, and authenticates the user in the same conversation. Nishant does add a degree of difficulty in this scenario as he ties the federation service to a provisioning service.  Grabbing attributes from the SAML token, creating a SPML message, and handing that to a provisioning service is possible, but as a commentator points out this sort of interop isn’t spec’ed out so the heavy lifting is left to the service provider.  And even if the service provider doesn’t want to directly link its federation and provisioning services, it still needs to grab that assertion attributes and create the account in the backend system. 

It turns out, to my surprise, that there are people doing this.  Parties in a federation agree to which attributes are needed and send those in their authentication assertions.  A process at relying party uses those attributes to provisioning new accounts.  This is a fairly lightweight and effective approach, but there are some catches to be aware of.

The first catch, as Nishant points out, is if the service provider needs attributes above and beyond what are in the assertion, there’s not an easy way for the service provider to ask for them.  To deal with this, the service provider has to present a registration screen of some sort to the user.  Compared to the first scenario in which the federated account is already waiting for the user, the second scenario is herky-jerky and will annoy/confuse the end user.

The second catch is deprovisioning.  The provisioning process hinges on an authentication event.  Deprovisioning cannot be activated on de-authentication.  This does leave the problem of how to remove accounts when people have left a federation partner.  In the approaches we have seen, when a new account gets built it has an expiration date associated with it that gets updated on every login.  After some period of time without an authentication, the account is suspended or deleted.  Not a bad way to go.

JIT Provision may in fact be “real” federated provisioning, but not provisioning, as a dogmatic, dyed-in-the-wool provisioning guy would immediately recognize.  While I take my dogma for a walk, this quarter Lori and Bob are going to looking into some of the intersection point of identity management and SaaS and I think they’ll have more to say on this type of conversation in the coming months.

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).

Sxip-Ping to a new beat

Bloggers: Gerry Gebel and Bob Blakley

Today, Ping Identity announced it is acquiring Sxip Access, the portion of Sxip Identity that provided identity management for software-as-a-service applications. Sxip Identity will still exist and focus its energies on Sxipper and other Identity 2.0/Web 2.0 technologies.

This appears to be a good strategy for both parties. Sxip is free to focus solely on the realm of user centric identity technology and approaches. Ping is able to immediately add support for SaaS applications to its federation portfolio, bolstering is ability to address the growing needs of organizations with distributed applications and a dispersed workforce.

Of course, adoption of SaaS applications is on a strong growth trend across the industry so there are many vendors seeking to enter this market and provide potential solutions. For example, TriCipher just announced their myOneLogin hosted authentication service that supports SAML and a number of other authentication mechanisms, Conformity is developing security, audit, and identity solutions for SaaS applications, and Symplified is working on identity on demand offerings for SaaS (Symplified and Conformity offerings are at the beta testing stage). It turns out, of course, that federation protocols don’t address some single sign-on scenarios if your workforce doesn’t adhere to the preferred confines of the SAML protocol. While technically feasible, it is can be difficult, in reality, to accommodate workforce members authenticating from on premises, from partner locations, or while traveling.

It appears also, that SaaS vendors have gotten more serious about authentication security as a result of recent published attacks against SalesForce.com. In summary, the acquisition, recent product offerings, and multiple startups suggest a segmentation for SaaS applications. First, there is a server side SaaS federation market and second, a client side consumer authentication as a service market. Both segments are good developments and necessary for the industry. Indeed, both segments are likely to grow over time.