Burton Group Identity Blog

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 and TriCipher 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.

Moving beyond command and control

Blogger: Gerry Gebel

Lately, I’ve been thinking a lot about the big challenges of the identity management industry as it’s currently constructed. The tag line I’ve been using is that “the end of command and control is near” – as far as the way we approach the administration and control of access to systems and resources. Our collective IT admin culture is to control every aspect of access to systems in our domains – registration, credential issuance, authentication, access administration, and so on. Such an approach is reminiscent of the x.500, top-down hierarchical ways that are so difficult to implement within dynamic, fluid organizations. This works relatively well, however, if most resources and users exist under the same roof – but that is rapidly changing as businesses and organizations become increasingly distributed. Can IdM technologies and administrative practices keep up with the pace of change?

The current generation of IdM products actually reinforces the traditions of centralized control structures. Technologies such as user provisioning, federation, and of course PKI rely on excessive coordination and orchestration to be optimally implemented. Highly distributed and massively scalable organizations can’t operate in this manner, and it’s not too far from your future to tackle problems like: onboarding 100 million new users during a weekend marketing campaign, enabling 500 new joint ventures or partnerships and decommissioning 600 others in a couple months, or operating an application that reaches a billion users. How well do you think it will work with today’s tools and approaches?

Evidence of change and evolution is all around us. The globalized economy applies pressure to and creates opportunities for modern organizations. Enterprises are driven to focus on core competencies – and outsource or offshore every thing else. Software as a Service (SaaS) companies continue to emerge and are growing steadily, some studies estimate that SaaS applications will represent more than half an organization’s business application portfolio over the next 5 years.

Executive management understands new business dynamics and seeks ways to leverage it for business advantage. IT and security departments, for the most part, haven’t gotten the message yet. It’s hard to let go of the command and control mindset that’s been ingrained in our thinking. You’ll recognize the ailment if you see or hear symptoms like:

• Access to our applications is only permitted if we issue the credentials

• I don’t trust their identity management systems or practices

• We must collect as much data on partner users as we do for our own employees in order to vet them

• “Can’t we solve this with PKI?”

Technologies like federation help us make incremental advancements beyond the command and control approach. If we permit authentication to occur outside our domain and project this information through a federation exchange, that’s a sign of progress. However, federation products, as they are currently constructed, still require considerable coordination between parties in order to establish the connection:  we focused on this issue at Catalyst last year. So, it was interesting to see the recent video sparring between Sun and Ping Identity regarding what they’ve done to address this from a technology perspective. To follow up, we recorded a podcast this week with Sun, Ping Identity, and Covisint – which will be available soon on the podcast site.

More incremental change is what we can expect in the near term until different identity business models emerge. Similarly, the introduction of OpenID and information card systems purport to change the dynamic by providing more user control over identity data, but this is in name only – business still determine what attributes are required to complete an e-commerce transaction and the user can select an information card that matches the business’ criteria. Real change happens when third party identity agencies and intermediaries proliferate and are utilized by Internet properties. Identity oracles, as described here, are examples of intermediaries that are beginning to appear in the marketplace.

Identity-based intermediaries and agencies handle the heavy lifting of identifying and vetting individuals, freeing enterprises and other relying parties to concentrate on managing access to applications. It’s another step toward more scalable and manageable business applications. At Burton Group we are dedicating a fair amount of time to exploring new identity business opportunities, in addition to all of the more tactical research areas we cover. Please join in the conversation throughout the year and especially at Catalyst in June and October.

Concordia meeting at Catalyst

Blogger: Gerry Gebel

We played host to the latest Concordia meeting earlier this week at Catalyst. It's been so busy, I'm just now getting around to posting a few comments. Others have published some excellent observations here, here, and here.

At the meeting, end user organizations (AOL, Boeing, GM, Gov of British Columbia, and GSA) described usage scenarios, highlighted key requirements, and offered sage advice to the standards development and IdM product communities. What a concept - injecting real user requirements into the standards process! Let's just say that more interaction is needed between producers of standards and products - and the organizations that buy and deploy them. There was a lot of commonality of requirements between the presenting organizations that remain inadequately addressed. You can see these requirements posted here.

Thanks to the Concordia team for holding their meeting at Catalyst, it surely enriched the conference.