In addition, Sampo Kellomäki, our Chief Architect, will be speaking in two panels that I'd highly encourage you to attend if at all possible. EIC is known for having world-class speakers from the ranks of enterprise technologists, thought leaders, and experts in most significant technology topics such as Identity Management and Governance, Risk Management and Compliance (GRC). It's put on by Kuppinger Cole, a highly respected analyst firm, and this year brings a very impressive list including some of the best known names in the industry and some good friends of ours - Felix Gaehtgens and Dave Kearns, just to mention a couple. The first panel Sampo is speaking in is User Centric Identity In The Cloud: Trust And Privacy, Trust Metrics on Wednesday the 6th at 16:30 following the break, part of the "Innovation" track. The second is Directory Services & Virtual Directories: Virtual Directory Services on Thursday the 7th also at 16:30 following the break, part of the "Best Practices" track. I can promise you that if Sampo has his way, the discussion will be interesting enough to keep you from dozing off after your meal. In fact, the whole agenda is full of topics that should hold your interest, but since there are four parallel streams of presentations, panels, and workshops, plus opening and closing keynotes every day it would be impossible to list them all. The full agenda is on the European Identity Conference 2009 site, so you can see it there.

In addition to the panels, presentations, and workshops, while you're at the conference I really hope you'll take the time to stop by our booth in the expo and give our team a chance to explain how you can put the performance of our products to work for you. Given the pressure of the current economy, it's more important than ever to maximize the use of your resources, and we can offer valuable suggestions on how to do that in your identity infrastructure if you'll spend a few minutes with us. Whether you are interested in virtual directory infrastructures or federated identity applications, we'll be happy to run our products through their paces for you and answer any questions you might have. See you in Munich!

Jeff Zukowski

We've done benchmark testing that shows both Symlabs Virtual Directory Server and Symlabs LDAP Proxy to be significantly faster than competitive products, and we're currently doing some more. In the near future, we'll post the results here and provide a complete picture of how we tested and what it means in different types of implementations. That will also give us a chance to review the new features in 5.0 for Active Directory (domain routing and cross-domain authentication), LDAP (virtual tree), and all the new plug-ins plus enhancements to administration and configuration tools.

For most attendees, the biggest reason to be interested in The Experts Conference is the information that the experts will dish out there. There is a whole agenda of workshops and educational sessions, covering some of the hottest topics in the industry. Of course, there will be a number of BOFs (Birds of a Feather sessions) which usually turn into some of the most interesting discussions at technical shows. We'll be participating in both the Virtual Directories and the Federated Service BOFs, so if you would like to share your views on either subject, hear ours, and take part in the discussion that follows, please join in. The Experts Conference is running from Sunday, March 22 through Wednesday, March 25, and the official BOFs are being held Tuesday, March 24, starting at 4:30 PM. You can get see the whole agenda and get more information on the show here, then check when you get there for specific locations or any informal sessions that are announced, and be sure look us up.

The general discussion about the performance overhead that a vds layer places on top of an existing data infrastructure has been adequately addressed by Mark Wilcox in his blog post. We typically see an increase in latency of around 2 milliseconds, although this may vary to between 1 and 4 milliseconds depending on your infrastructure and the amount of processing that you are handling within your virtual directory.

Keep in mind that cache has its uses, mainly to overcome limitations of your infrastructure, but also that it is usually not the only solution available. Some potential situations include:

• The back-end server cannot provide the requested throughput. However, this is best overcome by setting up additional replicas.
• Latency from the back-end server is too high. This one is usually best overcome with a replica that is local to the virtual directory server.
• The back-end server suffers from unacceptably low availability. For instance, the server might have scheduled maintenance shutdowns that render the source unavailable to client applications. This, too, is overcome with a replica.
• Calculating the result set takes too long in the back-end server. This usually occurs as the result of a very complex SQL query that requires too many external joins. In this case, it's better to redesign your provisioning workflows.
• The client application is brain-dead and performs the same query many times in a row - this is the only case in which I've seen true benefits from using cache in a virtual directory server.

We realize that real world environments can't always (or even often) be filled only with ideal solutions, and we've tried to account for that in the design of our products. For any of the cases above, if the client has some limitations that do not allow the preferred strategies to be employed, we provide flexible caching options in Symlabs Virtual Directory Server and Symlabs LDAP Proxy v5.0.

I hope that in everything that I have said here, I have made it clear that I do not think that a cache is the proper solution to handling performance issues. In general it should be considered more as a band-aid that can be used in a desperate situation. In this vein, I fully agree with the comments that Clayton Donley made in his blog post back in April last year.

One final note, I have to correct the math in Tim Paul's blog post. If your server does 5000 queries per second, the latency of each query is NOT 0.2 milliseconds (1/5000) - in reality you have multiple client connections being served at the same time and even multiple asynchronous requests over those connections. Modern directories have search latencies between 1 and 20 milliseconds.

Antonio Navarro

I hope I have given you a enough of an overview for this exciting environment that we get watch unfolding firsthand, and are fortunate to participate in creating. In the event that you have any questions, are interested in trying Symlabs Federated Identity Suite for yourself, or have some ideas you'd like to explore, please visit our website. You can download our products, obtain more information, or contact us with your suggestions.

Pablo Sánchez

As already mentioned here in earlier posts, we've added a lot of improvements to all three of these products in the past several months, and we'd love to show them off for you. Of course, we encourage you to take in the rest of the agenda, since there's a wealth of informative presentations and panels on tap, just don't forget to pay us a visit while you're in the area. We're looking forward to seeing you.

Jeff Zukowski

Jeff Zukowski

In order to deliver the examples described in the first part, network operators (I'll call them Telcos for convenience, but the world is changing and so are the players) generally want and need players of another type, the application service providers (ASPs), to step in and help to create the complete end-to-end service that a user experiences. By providing applications and services that run over the Telco's network, ASPs provide a valuable piece of the puzzle. This is because the level of demand, pace of development, and variety of possible services would strain even a Telco's resources if they tried to chase them all and develop them in-house, by themselves. But, in order to take advantage of ASPs as part of their services architecture, Telcos must expose their network infrastructure to these outside companies.

An ASP-Telco "symbiotic" relationship has the potential to create some truly interesting services, but it requires that each party take risks. For ASPs, the risk of innovation is pretty high - if they create something that nobody wants, it can be a total loss. And even if they have success, they need to be careful to protect their intellectual property. But, the ones that are successful can make money on a global scale through the power of a Telco channel, and the capital investment required for an ASP is modest compared to a network, so there is plenty of motivation for risk-taking. For Telcos, a rapid path to new service offerings with a big selection of potential ASP partners (therefore a big selection of innovative services) translates into maximum efficiency for investing their own resources. More important, it delivers the ultimate reward of an exciting network that attracts new subscribers, retains existing ones, and generates new traffic while also increasing existing voice and data volumes. In today's highly competitive environment, that's a path they simply must be on to ensure their survival.

What about that thorny issue of opening the network to “outsiders”? That, of course, is the major risk for Telcos. By doing this, they let others introduce components that could severely impact their traffic engineering or interfere with network management. But, the tools they already have are generally sufficient to maintain control of their network resources. The more unpredictable and unmanageable problem is security – and this doesn't just mean security for the Telco, but for any information flowing through the network.

In the type of infrastructure that we're heading for, where services are created through a mashup of applications and transports, the protection of sensitive information is a very complex issue. Sensitive information is a multi-dimensional problem in this environment because every party involved in the service transaction has some of their own at stake, and must respect some from the others.

For a Telco, the first task is protecting access to their network, which they have historically accomplished by being “restrictive”. In the new environment, maintaining an interface that appeals to a wide range of ASPs is critical to attracting them. That means letting them express their applications fully on the network without forcing them into major developments to match some unique API. At the same time, Telcos need to keep on ensuring the safety of information that they move about to protect the personal data and identities of their users.

ASPs, on the other hand, during their shorter history, have operated in a more open and collaborative environment than Telcos. Keeping their user information and identities secure has been something they've managed to accomplish while inter-operating with a wide variety of partners. But, they have enjoyed the freedom to manage their applications in a far less demanding and far more forgiving service environment than the infrastructure we're heading toward. Soon, minor issues they handled easily such as obsolete or redundant identity information in their user directory, or incomplete data and record update problems, become major problems in a global-scale service which is supported and branded by a Telco that demands a spotless image to make gains against their competitors. If they exposed customers to identity theft, massive spamming, or other scams through their service, they'd be responsible for a public relations disaster befalling their Telco partner which would seriously damage the relationship, not to mention their own public image.

In order for this architecture to work nicely, all the players need to be able to trust the others to do their part for security. They can see that that this requires a common set of standards that everyone embraces for these security functions, one that lets any ASP work with any Telco to create end-to-end services for any customer. Certainly vendor-specific standards could be used (and doubtless will be in some ways – more on that later), but a more flexible solution is an open standard that ensures ASPs and Telcos can inter-operate no matter what their platform choices. From our view so far, SAML 2.0 and ID-WSF are ideally suited for this, and are well positioned to become the solution of choice. These standards are a centerpiece of our identity management products, so a legitimate cry of favoritism is acknowledged, but in actuality this is not a heavily biased opinion. We support other standards, including vendor-specific ones, in Symlabs Federated Identity Suite, and this position is based on our work with all of them. It is a collection of our experiences in customer deployments, and perhaps more important in demonstrations and trials with the larger community of organizations seeking good real-world solutions that has led us to this viewpoint.

This is a good place to pause for now, but in the next (and last, I promise) part of this discussion I'll go into a bit more detail on how SAML 2.0 and ID-WSF standards can operate to everyone's benefit in this architecture.

Pablo Sánchez

Most people are regular users of various mapping and location services on their desktop, and now a lot of folks use location services on their mobile phones as well. When coupled with GPS-enabled phones, these familiar applications take on a new usefulness by reacting to changes in the user's environment. Similarly most people have established communities that shape their online activities according to relationships and interests. While for some it's still email and IM that manage their communication with those communities, for many it's rapidly evolving from a combination of those plus Web 2.0 tools on the desktop to mobile interfaces that give them rich interaction with their friends, families, business associates, interests, and urges whenever and wherever they choose. And it's becoming clear to many of us that this is a sweet spot for mobile applications - not just what media can I access, but how can I utilize it now, who can I share it with now, where can we meet to experience it now, and what can make accomplishing that easy for me ... now.

The application that most recently prompted me to write about this is Wizi. Wizi is the free location sharing and traffic information application that won first prize in the Orange API and Widget contest. (You can get it at www.wizi.com.) It has obvious uses for families or business people who are coordinating a schedule because it combines some key attributes of daily life in a dynamic, real-time way - where relevant people are, their destinations or meeting places, how they'll get there, and what's in the way. It can do similar duty for groups with other interests, such as when you want to choose between attending an after-work party, joining some friends for a dinner and a movie, or going a football game where you'll see lots of acquaintances who cheer your club. And, these are the obvious uses - only the collective imagination of a Web 2.0 enabled world can tell how it goes from there.

So, what does a company that specializes in Identity Management, Virtual Directories, and LDAP have to do with any of this? I'll suggest an answer to that by posing a different question: how much of the information that needs to be shared in the scenarios above would YOU like to have cross all groups? While you may want your family members to have your location at any moment in time, is that something you'd like visible to all the members of the football club? And for that matter, would you be pleased if your preferences such as football club or other affiliations was open to all your business colleagues? For most people, their real-time location and their affiliations are things they want to share very selectively. And, after you give it some thought, you'll probably agree that we're only scratching the surface in conceptualizing the schemes we'll really want to have for managing information that discloses our real-time, activity-centric, choice-driven self as it becomes a dynamic attribute in our daily lives. It's about TRUST - who and what gets it, when, and where.

In the collection of networks and applications that support delivering this vision on mobile phones, there needs to be an infrastructure that allows this identity information to be accessed and moved quickly, shared securely, managed actively, delivered flexibly, and operated on automatically in order for the end-user experience to be powerful, satisfying, and easy-to-use. And, if it isn't, then there won't be a sweet spot, after all. This, of course, is where Symlabs specializes - in that infrastructure and in the sharing and management of that information. That's why we've been working with Wizi on APIs, with BT and Intel on Identity Capable Platform (more on that later), and with Liberty Alliance on Advanced Client and Trusted Modules. Sound complex? It is, but in Part 2 I'll talk a little bit about how those technologies come together and how they work to deliver an efficient, trust-enabled platform that hits the sweet spot.

Pablo Sánchez

"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