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

Cloud SSO Interop Demonstration

Blogger: Gerry Gebel

If it's time for Catalyst, then it must be time for another interoperability demonstration! This year we are focusing on standards-based single sign-on to off-premise or cloud hosted applications. Of course cloud computing is all the rage this year and many enterprises are pursuing the benefits of utilizing SaaS applications plus directly accessing with more of their partner's applications. Such application scenarios can create additional usability and administrative burdens - and the purpose of this demonstration is to highlight how federation standards address the usability concerns.

Federation standards, such as SAML, WS-Federation and even OpenID and information cards can and are being used for authentication of users to off-premise applications. This demo focuses the attention to SaaS or cloud hosted applications and attempts to meet several goals, including:

- Show that federation standards are mature technologies, usable in many scenarios
- Illustrate that SaaS application vendors are already using federation standards
- Emphasize that enterprises should require SaaS support standards for SSO

In the past, interoperability demonstrations typically utilize a sample application during testing. This year, the demo includes real commercial applications - thanks to participants such as Cisco WebEx, Exostar (hosted SharePoint), eXpresso Corp, Google Apps, PivotLink, SalesForce, and even Burton Group's client web site. Other participants contributing from the federation software side include Arcot, CA, Cloud Identity, FuGen Solutions, IBM, Microsoft, Novell, OpenIAM, Ping Identity, RSA, Siemens, Sun Microsystems, Symplified, and TriCipher. FuGen Solutions and JanRain have also been developing some advanced scenarios to demonstrate how higher levels of assurance can be achieved in a federated authentication. Other organizations that have also participated include Azigo, Information Card Foundation, Microsoft Live ID, MySpace, Plaxo, and Yahoo!. Many thanks to all the participants who have been working over the last few months to bring this interop together!

A special shout also goes to Ping Identity, TriCipher, Symplified, and CA for their sponsorship to help cover interop expenses! Other sponsorships still available...

So, the interop demonstration is another reason to join us in San Diego for Catalyst - hope to see you there! Catalyst takes place July 27-31 and the demonstration will occur on the evening of July 29.

What federation protocols do you use?

Blogger: Gerry Gebel

We are often asked what federation protocols are in use or are the most popular. Concordia members want answers to the same questions and they've put together a survey that is open until May 1. The results will be posted on May 8th, so please take 5 minutes to answer the survey questions. 33 people have responded so far and it would be great to have a large sample size to see what is really happening in the industry.

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.

The Value of SPML Gateways

Blogger: Mark Diodati

A grateful “thank you” goes out to James McGovern, who steered me to Project Keychain and Jerry Waldorf’s associated blog. Project Keychain is an SPML gateway which leverages Sun’s open source enterprise service bus (fittingly called OpenESB). You can find Project Keychain’s list of supported target platforms (including LDAP, RACF, and salesforce.com) here.

Recently, I was asked if there is any value to using an SPML gateway. I believe there is. A picture is worth a thousand words (a cliché to be sure, but a good one), so here are a few thousand words. This picture describes the provisioning world, pre-SPML. I think we’d all agree that the world would be a better place if provisioning systems did not require connectors or the use of a proprietary API to manage users.

Currently, there are a few target platforms that natively support SPML for provisioning. Cloakware’s Password Manager (a privileged account management product), Imprivata’s OneSign and Citrix’ Password Manager solutions, and SAP NetWeaver come to mind. The list of target platforms which support SPML is slowly growing. With SPML support built into the target platform, organizations can readily integrate the platform into the provisioning environment because they can use the existing, standards-based framework (SPML). Also, a standards-based approach means that component upgrades (either the provisioning system or the target platform) are less likely to “break” the provisioning process. This picture describes the goal of SPML – provisioning users without connectors or proprietary APIs.


So, what are the benefits of the SPML gateway (as personified by Project Keychain)? One benefit is the ability to insulate the complexity of the target platform’s proprietary API from the provisioning system. This insulation means that the creation of a custom provisioning connector is not required, and any changes to the target platform’s API will not break the provisioning process (though it does place the burden on the SPML gateway). Another benefit is a smooth transition once the target platform natively supports SPML in future releases, because the provisioning system can speak directly to the target platform without the gateway. This picture describes a mixed environment with a provisioning system using SPML to manage users.

SPML may fix the plumbing issues with provisioning, but the user attribute schema issue remains. The provisioning system (that is, the SPML requesting authority) and target application (in the simplest architecture, this would be the combined SPML provisioning service point and provisioning service target) must use an agreed-upon set of attributes. The provisioning system must then map the SPML attribute schema to its internal schema. The provisioning system must do this for every target application, as it is likely that each target application will require a separate attribute schema. For what it is worth, SPML v2 made the division of service and attribute schema much easier. Burton Group’s SPML document discusses this issue. You can find the document at http://www.burtongroup.com/Client/Research/Document.aspx?cid=848 (client subscription required).

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

Microsoft and the SAML protocol come together in Geneva

Blogger: Gerry Gebel

At the PDC conference this week, Microsoft announced support for the SAML 2.0 protocol as part of a broader announcement regarding the beta release of the Geneva platform. Don Schmidt and Mike Jones of Microsoft also posted comments on the announcement. Geneva is the successor to the Active Directory Federation Services (ADFS) product and the Zermatt developer framework announced over the summer and has a broad scope as Microsoft’s “claims based access platform.”

Geneva includes the runtime server apparatus to support claims based applications, a developer framework for building those applications, and an enhanced Geneva CardSpace client. This is another positive step for Microsoft as this announcement addresses one of the main pain points for its customers that want to operate in many federation scenarios without imposing a specific protocol on partner organizations. Geneva, according to the announcement, contains support for WS-Federation, SAML 2.0 IDP lite and SP lite profiles, the GSA profile used by the U.S. federal government, WS-Trust and information cards. Finally, Microsoft customers will be able to interoperate in a heterogeneous federation environment using Microsoft tools exclusively. Some early interop testing has already occurred with Internet 2 Shibboleth, IBM’s Tivoli Federated Identity Manager, and Ping Identity PingFederate. 

Microsoft’s Geneva announcement moves applications toward a cleaner architecture that rely on shared services for authentication as well as authorization information. The next step we’re waiting to hear about is entitlement management and policy enforcement. Today, that is still handled by the developer within the business application. Will Microsoft also externalize that function a la entitlement management tools?

Now for the bad news… Can you wait until late 2009 or 2010 for Geneva? Yes, I know you’ve asked for this for at least three years now. Yes, I know that managing SharePoint access and federation is very painful but you’ll have to wait for some unspecified period of time before SharePoint - and other Microsoft applications – utilize the Geneva platform. Additional prerequisites, such as migrating to Windows Server 2008 and Windows 7, will likely be necessary to realize all the promised enhancements. Bottom line: you can continue waiting for Geneva (final composition of features subject to change – you know the drill), implement unsatisfactory workarounds, build some custom code, or look to the third party market for tools that provide enhanced functionality.

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.