Burton Group Identity Blog

How sturdy is the house if the basement is crumbling?

Blogger: Mark Diodati

We’re seeing some interesting things in the UNIX security product space – an area that has been traditionally considered “old school” identity management. After all, these products precede provisioning and web access management by a country mile, right? Some of it is the realization that enterprise applications cannot be secured unless the underlying operating system is secure. But some of it is the interaction we’re seeing between the UNIX security, Active Directory bridge, and privilege account management products. These products are different pieces of the puzzle working together to solve security and compliance problems.

Burton Group is currently researching UNIX security products and deployments. The list of UNIX security products includes:
•    CA Access Control
•    Centrify DirectAuthorize
•    Fox Technologies BoKS
•    IBM Tivoli Access Manager for Operating Systems (TAMOS)
•    Novell    Fortefi
•    Quest UNIX Privilege Manager (UPM)
•    Symark PowerBroker

I am interested in hearing about your enterprise experience with these products, including vendor selection. I also want to speak with you if you have a centrally-managed sudo deployment across your enterprise. You will have an opportunity to influence our research, and I’ll share what we have learned about the market, products, and deployments. Please contact me at mdiodati@burtongroup.com.

Satyam, Auditors, and Independence

Blogger: Mark Diodati

I began my career as an auditor in the early 90’s at a “Big 6” CPA firm. After a long day at a remote engagement, the audit team went out for dinner. I’ll never forget the question that we stumbled upon, because it seems to come up often in the news.  Can auditors be independent if they are compensated by the companies they audit?

The job of the firm is to certify that the company’s financial statements (e.g., balance sheet, profit and loss statement) are accurate.  Without auditor independence, the company’s financial statements cannot be trusted, and the entire financial system is at risk. Investors can lose their money (and employees can lose their jobs) when an apparently strong company suddenly goes under.  In this scenario, the company frequently “cooks" the financial statements to meet financial goals (e.g., revenue numbers and expense ratios).  The company gets the audit firm to certify the deceitful financial statements, either by hoodwinking the auditors or applying subtle pressure to “ignore” certain areas of the business. Enron, Satyam, and WorldCom come to mind. Two of the partners at PriceWaterhouseCoopers (the firm that audits Satyam’s financial statements) have been arrested.

Most of the financial auditors I’ve come across are ethical and diligent.  They realize the importance of their endeavors and do a great job.  Additionally, the Sarbanes-Oxley regulations proscribe audit firms from doing customer consulting engagements (a very lucrative income source), which improves independence.  Still, I can’t help but think that the current compensation mechanism makes auditor independence (and importantly, the appearance of independence) an uphill battle.

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

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