Identity Infrastructure Is
Our Area Of Expertise

The subjects discussed here include technologies, standards, architecture, implementation, and applications ... a broad range, to be sure. Each area is evolving rapidly due to the dramatic increase in scope and importance of identity for services and applications. LDAP, virtual directories, federation, and SSO are now key ingredients in an IT infrastructure. The ability to get maximum performance from them is absolutely critical. We are fortunate to have a "behind-the-scenes" view, and hope the observations we share from that perspective prove useful to our readers who care about these topics.

Entries in Federated Identity Management (11)

Wednesday
May122010

Impressions From EIC 2010

This year's Kuppinger-Cole European Identity Conference confirmed that many of the players in the identity market are now trying to work more closely to improve future technologies and increase their uptake. The conference centered around 'the Cloud', a rather nebulous term for services provided over the Internet. As expected, discussions focused on security issues and on ways in which identity data could be leveraged to improve business in an environment where data is becoming increasingly distributed. In summary, it was apparent that, while some areas of contention regarding security have been settled by agreeing that different protocols should be used to achieve different ends, there are still many issues which need to be resolved.

As for improving revenue and management in the identity sphere, things seemed a lot more vague, and mostly hinged on the hope that businesses would come to see the benefits of these technologies on their own. This was most evident in a talk about Identity Cards, where roll-out approaches vary widely. The German approach enforces compulsory enrollment but offers services to businesses that may help reduce infrastructure costs, while the Swiss approach pushes the business cases for uptake but allows for voluntary adoption. Although some interesting ideas about potential ways the technology could benefit businesses were presented, it will only become clear over time whether businesses actually see these benefits.

Perhaps the most positive aspect of the conference was the impression that many of the big players in the market are trying to work together toward a common goal. However, opinions are still fairly divided, and I was somewhat concerned to observe a few high-profile players in the industry suggest that identity federation through SAML (and, in particular, the work that Liberty Alliance has done, now continued by Kantara Initiative) looked like it would die in the water. This thinking is a little uninformed and, when chatting with other visitors to the conference, it was good to hear that SAML is ubiquitous in the Australian education sector and is widely used across Sweden as well as Denmark in various other governmental sectors.

This confidence in SAML was certainly reflected in a talk by Fulup Ar Foll, who accepted that while OpenID had won ground in the Web 2.0 space, SAML is the natural choice in the commercial and enterprise sphere, as is InfoCard for user interfacing and identity selection. This unofficial armistice between competing technologies has allowed the market to move forward, and everyone in the identity market seems to agree that authentication is a necessary evil, but not the end goal. Now that we have settled some differences over the roles that these technologies play and the arenas in which they belong, we can start looking toward ways that they can enable other identity services to provide real and tangible benefits for businesses and consumers.

Although touted as an 'experts conference', it is clear that the real goal was to educate potential customers and vendors about new identity technologies. Actually, many of these technologies are not really that new. As already mentioned, the Liberty Alliance federation technologies have been developed over the last 10 years or so, and InfoCard has been in development for almost as long. Instead of explaining the practical usage of many of these technologies and demonstrating them in action, the conference speakers still discuss them in a very theoretical way. In talking to many of the integrators and visitors attending the sessions, I sensed that there was a general frustration with this tendency to keep to the theory and to continue talking about the future. Integrators felt that there was little focus or guidance on how to handle the very real problems that they face today, and that all of this looking toward tomorrow (when things will be much better) was not genuinely helpful.

A few of the visitors seemed overwhelmed by the sheer mass of acronyms, protocols, and jargon that was being used. Perhaps it would be fair to say that this type of conference is simply not geared toward people who lack an understanding of the basic theory already out there - but if one needs to be grounded in theory to really understand all of the talks, then there should be little need for the talks to remain theoretical. As an industry, we really need to be careful of not simply 'blinding our consumers with science'.

There seems to be a genuine need to balance conferences like EIC with some advisory workshops where integrators, developers, and architects can learn how to begin working in a direction that will help resolve current issues in a way that won't paint them into a corner in the future. I attended the Authentication and Authorization track entitled 'How to make your software security architecture future-proof' which was presumably intended to have precisely this effect. The panelists pushed the work they were doing and suggested moving away from connection-based authentication and a 'pull-based' identity infrastructure. However, there was little guidance on how to actually achieve this, or how to work it into an existing architecture that more than likely would be built around these types of technologies. The obvious time limitations in a big conference make it difficult to move beyond a high-level schematic of what these technologies involve and into any deeper discussion, so it is hard to be very critical of this. However, it may help to garner support if we can show practical examples of how these technologies are solving problems right now. Indeed, this was highly evident in the talk on OpenID development being done at Microsoft, where we were able to see a prototype solution to many problems using OpenID, as it currently stands, in action. More kudos to you, Ariel Gordon.

To illuminate my perspective for these comments, I'll note that Symlabs has an interesting history. Our core product is designed to resolve many of the immediate issues associated with distributed identity data and connection-based authentication. Much of our software is built around the theme of dealing with problems that people face today. Over the years, particularly through our involvement with Liberty, we have also genuinely explored future technologies. We built Symlabs Federated Identity Suite around many of these concepts. In this way, we have attempted to maintain a presence in both arenas. But one thing is clear to us - while interest in federation is slowly picking up, the majority of our customers are looking to solve today's problems today.

EIC 2010 in Munich was a great opportunity to meet some new people and catch up with many other familiar faces. It was interesting to see how many of the issues that used to be so divisive are now playing out, and it was a genuinely positive experience. I just hope that, when the next one comes around, the experience is a little less ethereal and we see a bit more of an effort to address the problems in existing infrastructures so it can match up to the forces driving these technologies.

Rowan Puttergill

Thursday
Sep252008

Trust In New Mobile Applications - Part 3 (Conclusion)

Although we've had a bit of a gap in our thread on this topic, I'd like get back to it at last and finish it up. Working from the architecture I described in the last section, let's assume this view continues to develop, and Telcos push ahead with implementing SAML 2.0 APIs as a general rule. For ASPs, then, adopting this open security model will be both straightforward and very beneficial. They'll have plenty of options for adding the technology to their application that will allow the widest variety of ASPs to participate, no matter what underlying hardware or software they built it on. When their application needs to validate itself to the Telco network, it can use standard SAML 2.0 authentication methods to do it. When it needs information from the user's profile to incorporate into the service, it can use standard ID-WSF application queries or something more advanced such as People Service, if it's available, to obtain it securely.

The fact that SAML 2.0 and ID-WSF are open standards not only means a level playing field for all the ASPs and Telcos in terms of functionality, it also means solid security for the information under their control. But, while SAML 2.0 and the various ID-WSF protocols are the main instruments for securing identity information in this environment, the "identity-related services" that are defined in the ID-WSF model will play an important role in the big picture for mobile users.

Going forward, the applications that will be most desirable for mobile users generally need some personal and profile information to create their value, but that should not necessarily mean releasing any sensitive information. After securely validating the identity of the participants (the user, the ASP, the Telco) and their authority take part in a particular transaction at any place and time, the services in the ID-WSF model can be made available to all the participants for secure, controlled delivery of that personal information in a standardized format, while safeguarding sensitive information.

This gives ASPs and Telcos a safe, flexible, and easy way to utilize information in end-to-end services on behalf of a user. Because it's open and standardized, an ASP can develop to APIs that will work with a variety of Telco networks and Telcos can incorporate a wide range of ASPs and make their services available quickly - neither has to create special access, security, or formats to protect and exchange privileged information. In fact, using this model, the ID-WSF services that manage and deliver this information are themselves a potential market for ASPs.

While some types of information might naturally associate with a network, like user location or handset model, other types, like personal contacts and associations, are related to the user, and still others, like automobile registration are related more to an outside authority. ID-WSF is a rich environment that defines services such as geolocation, contact book, personal profile, and ID-DAP to not only objectify the information in a standard way, but also create a layer of security with access that can be granted or controlled by the appropriate authority (i.e., user, network administrator).

The end result, when developed and done properly, is the ability to create applications like Wizi, offer them in a variety of networks from a single ASP platform, and allow them to become a unique service experience in each implementation by combining other participating ASPs or features particular to that Telco. This, of course, brings us back around to the front of the discussion, and why we are so energized to work on standards activities, proofs-of-concept, and demonstrations with ASPs, Telcos, and the assortment of other companies and organizations that have similar interests. We really think this will result in some important and powerful capabilities that can dramatically change how people go about a great many of their daily activities.

Everything we learn, plus anything useful we create in these activities gets incorporated into Symlabs Federated Identity Suite. We tailor specific packages based on some of these activities, for example our IdP Telco package has everything they need to utilize the protocols, operate an Identity Provider, and connect to ID-WSF services in their network. We also offer packages designed to build and manage various ID-WSF services such as Personal Profile, Geolocation, or People Service.

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

Thursday
Sep042008

DIDW Offers Information, Ideas, And Hands-On

It's often hard to keep the realm of Identity Management in perspective and grounded in reality, but Digital ID World 2008, which takes place next week from September 8th through 10th at the Hilton Anaheim in California, is one of those rare opportunities to grab several days of discussions, workshops, and educational sessions on a wide variety of topics that will help you do just that. This year there's a full agenda of talks that offer user, vendor, and standards perspectives on the industry, but one of the things I think is most valuable is the opportunity to get your hands on some of the products you'll need to actually make identity management a reality for your environment.

Whether you're building new infrastructure or updating an existing one, whether it's for internal use, commercial opportunities, or government services - there's no substitute for demonstrations & discussion with the product folks to help you see how a puzzle assembles into your particular picture, in my opinion. We place a lot of emphasis on this, so we'll be there in booth 311 (around the center of the exhibition area in the California Pavilion) with demonstrations of Symlabs Virtual Directory Server, Symlabs LDAP Proxy, and Symlabs Federated Identity Suite plus experts from our team to answer your questions, discuss your individual requirements, and generally offer suggestions that we hope will be useful in your planning.

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

Friday
Jul252008

New Version Of Symlabs Federated Identity Suite Ready

For those of you who are currently using, testing, or just considering Symlabs Federated Identity Suite, I thought I should sneak in here and insert a mention that we've released version 3.5.0 with support for Windows Cardspace Information Cards.

This update provides Security Token Service (STS) in the Identity Provider (IdP) Server, and also as a standalone STS module that can be used independently. In addition, the IdP Server now supports Cardspace logins as an authentication mechanism, and it includes Managed Card Provider functionality for generation and ongoing management of Information Cards. If you'd like to try out these features, you can download an evaluation copy of the new version from our website at http://symlabs.com/products/federated-identity-suite/download.

Along the way, we made a number of internal improvements, for example we changed the credential verification process to squeeze out some additional performance. And, to make building secure identity-aware database applications easier in a Liberty Web Services environment, we've added some example implementations of ID-DAP Web Services Clients (WSC) and Web Services Providers (WSP) to the package that will give you a good head start.

So, there's a bit of something for everybody in this version, and you can be sure we'll continue to focus on adding versatility, reliability, and performance to Symlabs Federated Identity Suite. If there are any suggestions you'd like to give us for things to work on, please feel free to drop by our website and leave us some feedback.


Jeff Zukowski

Friday
Jul182008

Trust In New Mobile Applications - Part 2

To continue the discussion of how security and trust seem to be taking shape for applications and services in mobile networks, let me explain in a little more detail about the infrastructure that is evolving, and how its component parts need to interact.

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