Identity Matters

The time has come to finish up this discussion of the new Remote Administration Server (RAS) in version 4.0 of Symlabs LDAP Proxy and Symlabs Virtual Directory Server by describing how it actually brings a lot of benefit to a production environment. This, of course, is what our customers care about more than the technology itself (and far more than a philosophy debate with the MOTCL* (*see last post)).

Refreshing your memory from last time, before RAS (i.e., before version 4.0) each instance of Symlabs LDAP Proxy or Symlabs Virtual Directory Server and its associated instance of DSGUI were tightly coupled, one-to-one. For example, every server running Symlabs LDAP Proxy was also running it's DSGUI interface, and while this provided a nice graphical configuration and management tool, you had to access it through that server, and you could only manage instances running on the same server when you did. As production environments routinely started having lots of instances on lots of servers, our customers started asking for a way to simplify and consolidate their management capabilities.

Now with RAS, the architecture has been re-worked so that there are several options for managing complex environments, allowing customers to create the one that makes it easiest for them. The "core engine" in Symlabs LDAP Proxy or Symlabs Virtual Directory Server no longer needs its tightly-coupled graphical environment for configuration and management (as it was before version 3.0, when MOTCL roamed the earth). Instead, RAS allows an instance of DSGUI running on any machine to configure and manage an instance of the core engine running in any server, using fully secure communication of course. One ring to rule them all.

Using the RAS server is fully optional, so if you want run a local DSGUI in the server along the instance of its core engine, you can still do so ... and start managing multi-server configurations the moment you need to, and not an instant before. The rapid prototyping that DSGUI users are used to has not been lost, in fact you haven't lost the flexibility to manage any instance of Symlabs LDAP Proxy or Symlabs Virtual Directory Server from the command line, if that's what works for you. You have simply gained the flexibility to configure and manage them all easily from one place, or from several places using whatever division of responsibility and toolkit matches your organization needs.

Also, with the introduction of RAS we changed the way in which configurations are stored, so they are now platform independent. If you have several RAS instances running on different types of servers, you can simply copy and move the configurations among the servers with just a mouse click. This should come in very handy, especially in production environments where several instances have to be kept current, such as when fail-over scenarios or server replications are managed. It will also be useful where different environments are maintained for preproduction and production, or where different OS are used, for example initial testing done on a Windows desktop with production running Solaris. Now configurations can easily be created on technician's desktop, verified there, and  moved to a preproduction environment to begin load and performance testing in seconds, all without having to worry about changing environments, desktop sharing, or other cumbersome annoyances.

I can keep on talking about implementation details for hours, but at this point you should get the picture, so the next step is to prove it to yourself. Just download a free evaluation version from http://symlabs.com and check out how useful this new feature is. We are always interested in opinions (including from MOTCL) to help us keep improving the features offered in our products, so after you try it, any feedback you want to send us will be greatly appreciated.

Fernando García Vegas

At last we've wrapped everything up, and the new version 4.0 of Symlabs Virtual Directory Server and Symlabs LDAP Proxy is now official, so I can finally take a moment to elaborate on the Remote Administration Server (RAS) feature that I briefly mentioned last time.

"In the beginning ... was the command line" (an interesting, but a bit outdated essay by famous author Neal Stephenson) is the best way to describe how our family of products started. A long time ago (in a galaxy far away) Symlabs began with an extremely fast and robust multi-protocol proxy engine, designed to give large LDAP deployments functionalities that existing LDAP servers could not provide. It was impressive by itself, and it has become the "core engine" of our products today, since its extensive programming capability has allowed us to keep on building new features and functions. Even now, we're pretty sure that we have barely scratched the surface of what can be done with that engine.

But, let's face it, it was not the easiest tool to configure and work with - its extreme "command line" approach was bucking the trend that most enterprises were following. That's why we created DSGUI, our name for a Java-based graphical user interface that makes managing configurations much easier. DSGUI allows end users to start working with both Symlabs LDAP Proxy and Symlabs Virtual Directory Server in a matter of minutes. This feature has allowed us to serve more than the "big IT & Telco" shops that had the resources to work without a GUI, and has been a success from the start for a wide range of customers.

But, the addition of DSGUI was not without some resistance, as a few developers (let's call them "Masters of the command-line", from now on - MOTCL) still hold the idea that graphical interfaces are for the weak and feeble. Still, DSGUI's success helped demonstrate that MOTCL are not always right (some may say never, but that's another story), so after we shipped it we decided to take the next step and listen to more customer feedback about how to continue improving the usability of our products. And, that's how our Remote Administration Server (RAS) functionality came to be.

RAS lets us take full advantage of the graphical user interface and at the same time adapts our products to fit in all possible environments, even those that do not have a graphical environment for some reason. It gives end users the ability to manage Symlabs LDAP Proxy and Symlabs Virtual Directory Server configurations regardless of where they are installed, and also allows them to deal with several instances at the same time. So, if an environment has six different instances of Symlabs LDAP Proxy running, let's say four in the local data center and two in different parts of the country, RAS allows them all to be managed from one place.

Think of RAS as a "connector" between the core engine I described earlier and the DSGUI graphical configuration utility. It works as a daemon process running on the server along with the core engine, communicating between any instance of the core engine in Symlabs LDAP Proxy or Symlabs Virtual Directory Server, and any instance of DSGUI.

OK, so that's a bit about where RAS came from and basically what it is. Next time, I'll finish this discussion with a more in-depth explanation of how to actually use RAS and DSGUI to simplify configuration and management chores in a complex environment. Meanwhile, I'll refer to my earlier comment and recommend that you fill some spare time with Neal Sthephenson's book "Cryptonomicon", which should be mandatory reading for anyone working in the security and identity management field.

Fernando García Vegas

Since a recent Symlabs press release mentioned that the new version 4.0 of both Symlabs Virtual Directory Server and Symlabs LDAP Proxy are nearing their availability date, I thought it would be good to give everyone an update on how the work to wrap everything up is proceeding. And, the answer is ... VERY well indeed!

We're on still target to meet our general availability date, which will be very soon now, and more important than that we're on target to deliver all the benefits that this new release was designed to offer. We're getting good feedback which is telling us that the performance improvements are going to be as dramatic in real-world implementations as we predicted they would be. Speaking as the Product Manager and also one of the developers, this is the best news we could get, since every small percentage increase in the speed and throughput of such communications-intensive processes is a prize we fight very hard to win. But, as our customers insist, this is a championship caliber prize because it's the key to making their whole infrastructure responsive - and to them that means customer satisfaction, efficient operation, and fewer problems overall.

Not to diminish the importance of usability by putting it last, but version 4.0 also gives Symlabs Virtual Directory Server and Symlabs LDAP Proxy an improved user interface to make them much nicer, meaning faster and easier to configure into working applications, plus a powerful new feature to centralize administration of multiple instances on different servers. I'll write more on that later, but already I can see that we are getting very good reports on this added usability. And, since this means we're giving our colleagues in the IT department a shiny new set of tools, that makes me feel pretty good, too.

Fernando García Vegas

Hi! It's Felix again, and today I am going to write something about provisioning because it's a hot buzzword now. I first heard about it when I was working for several large telcos. Provisioning there meant to manage a subscriber's data (which is effectively the identity, together with many service attributes). You had to manage individual accounts on the voicemail system, the GSM home location registry, the customer care system, multiple service databases, and so on. That was quite a large process. Sometimes you had up to 20 (!!!) databases and LDAP directories to write or read to.

But then the word "provisioning" started popping up in the enterprise world as well. The same logic still applied, but usually the number of databases and the complexity was much below that of a GSM wireless operator. The promise of automated provisioning was that you could add a user, and then local accounts were created wherever needed. In addition to that, a new email address was added, and possibly an entry in the security access database for physical access. Many organizations found it convenient to trigger the initial adding of a new user from the HR system, which made sense. Other organizations had the security departments manage the master entries. That worked for them, too.

When I mention provisioning, I have to mention de-provisioning as well! De-provisioning is to delete accounts, and make sure they are deleted everywhere. After all, an organization would not want to give a disgruntled ex-employee any system access, or an email address at the organization anymore. I remember a very interesting article that Dave Kearns from Network World wrote in his Directory and Identity Management newsletter sometime in 2002. That's quite a while back, and Network World doesn't archive their newsletters that long. When I asked Dave to send me a copy of that article, he promptly did so - and told me that the part is actually from the book "The Perils of Provisioning" that Business Layers put out a few years ago as a marketing tool. So here goes:

"An executive in our company moved into a new house and had a telephone line installed that was connected directly to the company's internal switchboard. After some time, the executive left the company. Needless to say, the phone line was never disconnected. In the meantime, the house has changed hands several times. The real kicker was that the last time the house was put up for sale, it was marketed as having "free long distance" as one of its amenities."

Let's just step back a little bit and look at provisioning not as some pieces of software that synchronize other systems. Instead, let's think about provisioning and de-provisioning as a business process - every organization has one, even if it's not written on paper. If, when you first start a new job, you must spend a week going from one department to another shepherding the provisioning process through yourself, you can just imagine how much money would be lost through such inefficiency. Therefore, provisioning projects are all about transferring this process to automated software that does all the copying and deleting of data from one system to the other.

In the provisioning world, standards such as SPML (Service Provisioning Markup Language) have become quite popular, and that's understandable. SPML is a standardized XML-based protocol that lets systems communicate in a controlled way to add, modify, delete and query identity information. Standardized in this case means that you should (in theory) be able to connect different systems that all talk SPML. In practice, it's not that easy - but it can still be done in a few ways. SPML makes heavy use of DSML, another protocol based on XML that, in turn, borrows quite a bit from the LDAP protocol used to access directory servers (often called LDAP directories or LDAP servers). This means that SPML and DSML can be (and usually are) converted into LDAP requests that are then used to interface LDAP directories – unless, of course, the LDAP directory also talks DSML in a very efficient way. Enough about protocols - sorry if it made your head spin! I'll take a more detailed look at the protocols another time.

Usually, provisioning products talk to other systems in two ways:

* Connectors - when the provisioning systems talk to a remote system through a defined protocol.
* Agents - where special pieces of the provisioning system need to run on the target system to kick off required changes.

There is another case when provisioning systems can talk to other provisioning systems as well, but let's keep that out of scope so things don't get too complicated for now.

If you have the choice of whether to use connectors or agents, think first about security. When you use connectors, you are keeping the provisioning system at an arms length (speaking from the perspective of the particular user database instance). Instead, when you use agents, you will have to install another piece of software from the provisioning system on your user database instance, and give it full administrative rights there. The latter could be a political problem when different groups are involved, or it could be considered a security exposure if no internal security certification of the agent has yet been done by the organization. Connectors, however, talk to another system through a supported protocol that is being managed on the remote side entirely by the remote application. And - surprise! ... SPML pops up quite often in these scenarios.

Provisioning applications don't just serve the purpose of automating the synchronization of identity data. They should also be able to do some other important tasks, such as logging and auditing. In many countries, special legislation mandates that access and modification of specific financial (and other) data is fully logged and that people are held accountable. One that comes to mind is the Sarbanes-Oxley Act in the US. Provisioning software can assist in compliance by logging all changes to users and their profiles. In some cases it can also help to easily analyze what access a specific user had to particular data at any point in time.

So, computerized provisioning sounds like a hot technology. But it is not without problems and issues. One fundamental problem with a provisioning solution is copying the data itself all over the enterprise. Do you have experience with copying data from one to multiple servers, and changing the data, and making different requests every time? Well, I have and, let me tell you, in many different ways it can turn out to be a can of worms just making sure that every system is updated correctly, that no problems arise, and that undo operations will assure every change is perfectly rolled back. Also, there's a time lag between applying changes in different systems, and all kinds of errors can happen because of that. This all results in massive deployment projects, and lots of time spent making sure that everything runs smoothly. And, every time you upgrade one of the many systems that you're synchronizing to, be prepared for some more hard work to test that the synchronization operates correctly before you actually apply the upgrade. Business rules change all the time, and if the provisioning software is not well thought through, then reconfiguration is like a never-ending nightmare.

When we started Symlabs in 2001, provisioning was one of the things that we had already thought about. At that time, provisioning systems were not yet available, and we didn't focus on a "pure" provisioning system. Instead, we wanted to solve the problems of synchronization and copying data in a more generic way. Our flagship product, Symlabs Virtual Directory Server, was conceived as a virtual directory that could easily be extended to work as a connector or as an agent. It supports multiple protocols (including several based on SOAP and XML) to inter-operate in many environments. When deploying a provisioning solution, the Virtual Directory Server works like magical glue, and some of our customers are using it to simplify and accelerate their provisioning solutions - with outstanding results.

Hi, it's Felix again. I'm writing another entry to talk about provisioning, and I think it will be about as long as the last one on identity management by the time I'm done. While I'm finishing it up, I'd like to post just a few words about what we are doing here at Symlabs to turn some of these concepts into practical benefits for users. You see, we think this is not only an interesting field of technology to work in, but we really believe that once the infrastructure for identity management is rolled out so that everyone has access to it, the positive results for end users and providers will be tremendous.

It's our feeling that the picture of "what could be" is not widely appreciated yet (maybe because underlying technologies like LDAP, virtual directory, SAML, etc. are complex, or because a lot of different companies need to cooperate to deploy it), so getting the word out and proving that the solutions work in real world situations are high priorities if we want to lead the parade that delivers these benefits. And, we do.

With that in mind, I'd like to call your attention to a few events happening right now that Sampo Kellomaki, my colleague and Symlabs' Chief Identity Architect, is participating in for us. First up is ePortfolio 2006 in Oxford, England from October 11-13. This show is a huge international forum for the exchange of ideas about how to use electronic portfolio solutions in education, government and corporate infrastructures, and Symlabs is participating in the PlugFest on October 11 where we will demonstrate a solution for automated resume processing based on Human Resources XML interoperating with Liberty Alliance ID Web Services Framework (HR-XML and ID-WSF for those of you already familiar with the terminology). When this capability becomes routinely available it will let the HR industry incorporate a set of tools for identity-based and role-based access authorization to improve the security and operation of their online processes, while, from the user perspective, identity web services ensure the privacy of their information and simplify access to services with features like single sign-on. I'll talk more about these applications and individual pieces like single sign-on in upcoming posts, but if you can take advantage of a couple of industry shows that are right around the corner, Sampo will be delivering some very informative talks that we hope will give you a nice view of the picture ("what could be"), show you something about how it works, and maybe even get you to join the parade.

Sampo will be speaking at the ISSE 2006 Conference in Rome, Italy on October 12 about how to use the Liberty Alliance People Service in eGovernment applications, covering document submission in particular, such as corporate tax returns. At RSA 2006 Europe in Nice, France on October 25 he will be talking about Liberty People Service, but this time with a focus on consumer applications. Liberty People Service is the industry's first platform for managing social applications centrally, providing consumers (and enterprise users) with a single view of social relationships in a secure and privacy-respecting federated social network. Sampo will also demonstrate Liberty People Service at RSA 2006 Europe, by the way.

So, go look or listen if you can, and it would be nice if the parade gets bigger.