Category Archives: BMC Software

Not necessarily so complicated

Ashraf Motiwala of Identropy points to an interesting SaaS WAM offering from a company called Symplified. In praising Symplified, Ashraf makes this assertion:

Anyone who knows idenity knows that WAM infrastructures are rather complex. Agents, proxy servers, APIs, Policy Servers and a host of other moving parts.

Ashraf is correct that this is the case for most WAM products. But it’s not the case for all WAM products. The OpenNetwork/BMC WAM product (which was recently taken over by Symphony Services) could be deployed with nothing more than AD and access control agents on each web server. The access control agents served as both a PEP and PDP. No policy servers, APIs, or proxy servers required. The same accounts used for intranet login could be used for web access control and the policies could be expressed in terms of AD security groups.

In addition to AD, a slew of other LDAP servers were supported. No other databases were required, except if the customer wanted to audit web access, an RDBMS was needed in addition to the directory server.

None of this is intended as a criticism of Symplified. I can see a lot of value for companies in going with a SaaS WAM offering. Also I find their virtual appliance option to be very interesting and I would love to see them publish a study comparing the uptake between the two.

But for those that want do go with a more traditional software WAM solution should know that WAM doesn’t have to mean complex deployments. There are simpler ways.

Depressingly Familiar

Dave Kearns recently quoted some vendor numbers on the state of orphaned accounts in enterprises that are pretty scary. It’s not that I don’t believe the numbers. Quite the contrary, they are depressingly familiar. These numbers are very much in line with what I regularly saw at customer deployments when I was at EnableSolutions (later renamed Access360 and then acquired by IBM)… 10 years ago.

That’s really quite staggering when you think about. 10 years, at least a dozen vendors entering the market, and a handful of compliance regulations later the situation with orphaned accounts isn’t any better than where it started.

However I didn’t understand this quote:

Almost all current provisioning software includes modules to de-provision accounts, but that hasn’t always been the case. As I noted in an article about the first identity provisioning application, back in 1999, de-provisioning was in the road map for the second release.

In 1999 I was working on version 4.0 of enRole, an identity provisioning application. And yes, it supported deprovisioning as Dave defines it, and had for several years before then. I am also fairly sure Control-SA (then produced by EagleEye/New Dimension) also supported deprovisioning back then as well.

BMC and IdM

Felix Gaehtgens of Kuppinger Cole has some interesting observations about BMC’s new position on IdM (and gives me a nice mention as well).  Radovan Semančík has some interesting speculation as well. Both posts are well worth your time if you are interested in BSM or enterprise IdM.

And of course TalkBMC has lots of great bloggers talking about BSM and other topics.

The intersection of identity and ITSM

There has been an interesting discussion recently about the practice of application developers wanting to use SQL as a means of querying identity information rather than LDAP. You can read Kim Cameron’s thoughts about this here and Dave Kearns’ response here.

I don’t want to get into the whole LDAP vs SQL debate. Really what’s the point? LDAP has been declared the COBOL of identity and obviously SQL is the COBOL of data query languages. Since they are both really just COBOL, why argue?

But I would like to point out one application where issues behind this debate play out in the real world. That is the Configuration Management DB (or CMDB). The term CMDB really means two things. First it is the conceptual term in ITIL for the DB that stores the configuration for the infrastructure that is needed to deliver services. Second, it is the term given to a wide range of products from companies such as BMC, CA, and IBM, as well as a variety of smaller vendors.

The CMDB is intended to be the central data repository for ITSM applications such as Configuration Management, Change Management, Incident Management, and Capacity Management. A CMDB is a collection of Configuration Items (CIs). While each CMDB vendor defines CIs differently, they typically contain the following types information:

  • configuration data
  • Ownership (who is responsibl for this CI)
  • Relationship to other CIs

If you are interested in IdM, number 2 should jump out at you. Identity is an important part of a CMDB. Not only is the ownership part of a CI identity, identities may indeed by CIs themselves. For instance it’s not uncommon for one CI to represent a Unix system that is related to CIs for each account on that system.

As a general practice, CMDBs are implemented as relational DBs with associated management software and APIs (even though relational DBs are really the COBOL of data storage). Some CMDB vendors that are also IdM vendors have products that synchronize their CMDB with their IdM products. BMC has just such a product that pulls accounts from their IdM system and populates them into their CMDB as CIs.

Which is exactly what this discussion is all about.

In theory one could develop ITSM software that used a Virtual Directory approach to access the CMDB data and identity data. I think that would be an interesting and novel approach to the problem. But to date I am not aware of any ITSM vendor that has taken that approach.

Today if you are in the ITSM world you will either have a disconnect between your CMDB and your live identity data, or you will synchronize them. That’s not to say that won’t change. It likely will change, and the change may be something called CMDBf, but I will leave that for another time.

[Full Disclosure: my current employer, SunView Software, sells an ITSM system that includes a CMDB.]

Some advice about AD schema extensions

There was a little kerfuffle about AD schema extensions recently. Jackson Shaw smacked Mark Wilcox around about spreading FUD about Vintella and Mark walked it back a little later.

I thought I would offer some advice about AD schema extensions from the standpoint of having worked on a product that actually required AD schema extensions. The product that was originally OpenNetwork DirectorySmart and later became BMC WAM allowed you to write web access control policies based on the users and security groups in AD. But to do this you have to extend the AD schema. Of course the product also supported ADAM, iPlanet, and eDirectory so if AD schema extensions was an issue there was always an alternative. 

Now when Mark claimed that many companies have a policy against AD schema extensions he was quite correct. When Jackson stated that virtually every company’s AD schema has been extended he was also quite correct.

What gives?

It all depends on who is modifying the AD schema and why. Or put another way, just because a company is willing to modify their AD schema to deploy Exchange and Messenger, doesn’t mean they will modify their AD schema to support your product. Some companies will but some won’t.

At OpenNetwork we had many customers who would deploy a dedicated AD instance for their partners and customers identity (especially pre-ADAM). For these instances they didn’t really care if the schema was extended. Some customers chose the product for their corporate wide web access control and SSO and thus made the required schema extensions. But we did have a number lost opportunities where the potential customer wanted direct AD support, but wouldn’t make the required schema extensions.

The bottom line is if you are planning on developing a product based on AD, don’t require schema extensions if you can avoid it.

I have failed to communicate

Clayton Donley of Oracle makes some excellent points here about my “Elephant in the Room” post.  But I have apparently done a poor job in communicating the whole point of the post. In his post:

What I think his post misses is the fact that most LDAP access in most applications is poorly written, even when using ADSI or ADO to talk natively to Active Directory. I can’t count the number of virtual directory deployments that we’ve sold to help customers in environments that were nearly 100% Microsoft (ADO/ADSI-enabled apps talking to Microsoft AD). Many of these deployments were to get around bad schema assumptions, others were to get around topology issues or forest boundary issues.

While we sell virtual directory technology, we hate making our customers pay money to solve such tactical issues. We want to be layering on higher-order value.

So when Phil Hunt or others talk about the Liberty IGF project, what they’re really saying is that we want a better way to give application developers a way to code something in a way they understand and can do well rather than a native access protocol that requires specialization. So while LDAP isn’t going away and everything from virtual directories to identity buses will need to support native access over LDAP to be successful, not looking at what developers are learning and using every day would be a mistake.

Keep in mind that developers must integrate with a LOT of technologies to build an enterprise application or portal. For example, a portal may be integrating with HR, CRM, and ERP systems. That integration is increasingly happening via web services. Giving these developers a mandate to use a completely different type of technology to integrate identity will only make identity more specialized and less standardized and understood over time. That is a recipe for disaster.

I did not mean to imply LDAP was a better choice that Liberty IGF. I was in fact the BMC rep to Liberty TEG and am very supportive of their work. I also agree there are a lot of problems with LDAP and how developers use it.

But having been involved at some level in the standardization efforts of DAML, XRPM, DSML v2, SPML, SAML, WSDM, OATH, Liberty, WS-Trust, WS-SecureConversation, and WS-Federation. I have spent a lot of time working on identity service standards and developing implementations of those standards at several different companies.

But the hardest thing is getting adoption of these standards. The point of my post was not to suggest that standards for identity services other than LDAP aren’t a good thing. The point was that to drive adoption you have to accept the reality that AD and other LDAPs have the predominant mind-share today.

To many enterprises, LDAP is their one identity hammer. And they see all their identity problems as nails. If we want them to put down the LDAP hammer and pick up the IGF pneumatic impact wrench, we have to explain to him in real world business cases why it’s better. Because they  know the LDAP hammer will work and they already have it in their tool box. The IGF pneumatic impact wrench is a strange new tool to him that they must first understand and second justify purchasing.

Of course AD isn’t all identity in an enterprise. But for extranet identities you will have to justify why IGF or some other identity service is better than just throwing in an ADAM, OID,  or OpenLDAP instance. Or even a virtual directory like OVD or OptimalIdM VIS (for the .NET centric customer). The enterprise architects know they already have a wide variety of tools and APIs to leverage LDAP. They don’t yet have those for IGF and other identity services.

Bottom line – identity services will not reach the level of adoption to where you could say there is an “Identity Bus” until there are compelling business cases made for it. Enterprises not only have to adopt the identity service standards, but they need to make vendor support of those standards a selection criterion to drive adoption.

An interesting question not asked enough

Matt Flynn relays an interesting question about federation. The question essentially boils down to this:

How do we audit federation-enabled access to business services?

What I find interesting is not the question or the answer, but how often the question is asked.  A few years ago I made the utterly wrong prediction that this would be a big issue by now. With all the attention being paid to compliance in the IdM space over the past few years, there are several explanations as to why this issue is hardly ever discussed:

1)      Few businesses are really using federation to enable access to important services to their business partners.

2)      Of those that are many are using a federation service provider such as Covisint. Covisint supplies auditing tools and services to address this need.

3)      In some cases federation has been added after the fact to an existing partnership where access was granted via provisioned user IDs and passwords. In this case the service provider likely already has auditing capabilities that are still applicable after the conversion to federation. This was the case with several federation deployments I was involved with at OpenNetwork/BMC.

I had also predicted that this issue, along with the difficulty of establishing the legal agreements needed for federation would drive business partners to federation service providers like Covisint.