Identity Matters

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

We've recently been involved in some technology demonstrations that I think have a lot to say about how the future of security and trust in mobile networks is taking shape. As everyone can now see, a new breed of mobile applications is emerging that extend the Web 2.0 social networking and mashup metaphors into a pervasive space that users will tailor to serve them in the context activities that involve dynamic communities of their daily lives. Some good examples are coming into focus, and one in particular that we participated in took the prize at Orange's API and Widget contest in Portugal this April.

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

Hi, this is Felix again, and I'd like to point your attention to the 1st European Identity Conference in Munich, where my colleague Sampo and I will be attending and speaking. Sampo is highly engaged on the identity federation side, and he'll be giving a workshop with Conor Cahill from Intel on "Implementing Secure Liberty Alliance Services". This takes place on Thursday, May 10th, at 09:00 AM. I'm expecting it to be a very high-powered, hands-on and interesting session, where Conor and Sampo tell you all about the ID-WSF standards and how to boot-strap them. Sampo will also appear in a panel on Tuesday, May 8th, at 16:30 PM entitled "OpenCard, Higgins, Bandit & Co - Projects and Trends in Open Source Identity Management". This should be very interesting because it includes several of the people that are actively involved in the open source community.

I, on the other hand, will fence it out with our competitors in the Virtual Directory arena on Wednesday the 9th at 14:00. The title of our panel discussion is "Loosely Coupling Applications through Identity Information - The Future Role of Virtual Directories" and it will be moderated by Martin Kuppinger, one of the founders of Kuppinger Cole who are sponsoring the conference. We'll be discussing virtual directory technology and we'll answer all those pressing questions I know you have - why this is so much better than the old meta-directory approach, and what the future holds for directory integration. Afterwards, I'll be speaking about how to deploy a bullet-proof, highly available directory service. That presentation is going to be no-nonsense, hands-on, and full of information that I've gathered over the last five years (and which you can't find anywhere else).

I highly recommend that you try to attend this conference, and if you do, make sure you drop by and say hi! We're going to be exhibiting the latest versions of our LDAP Proxy, Virtual Directory Server, and Federated Identity Suite at booth G1 in the exhibition area. See you in Munich!

The idea of Authentication Context, as defined by Liberty Alliance and SAML 2.0, has been a subject of some interest lately. As a way for Service Providers and Identity Providers to add additional meaning to an authentication dialogue, it has great practical value to businesses.  Dave Kearns recently wrote an interesting article about it in his newsletter, and he was inspired by a post on Paul Madsen's blog that touched on the subtle power of context.  Dave asked to see more examples from the vendor community, and that was inspiration enough for me.

At Symlabs, we see our customers using AuthnContext for information about how a user was provisioned in the first place, and also how the user was authenticated for the current session. This requirement came originally from our customers who are wireless operators, but it makes a lot of sense for other service providers as well.

Remember that it is possible to buy mobile phone service through a subscription (post-paid, with a contract), or anonymously (pre-paid, without a contract). It all comes down to liability - the type of "trust" that you would want to extend to an anonymous user who paid cash for a mobile phone from the local drug store versus a user that you know and have had a business relationship with for years.

There are times when the context can have liability implications, therefore it is important to set this context appropriately and based on the business relationship. For example, a company may have tiered partnerships (i.e., "platinum", "gold" and "silver") with other companies. The tier could then be one of the factors used to determine the maximum liability allowed for different ID assertions.

Symlabs was instrumental in getting the mobile authentication contexts defined, because our wireless operator customers requested our participation in this area. Generalizing what we learned from the mobile world, the Symlabs Federated Identity Suite can be configured with any business logic, factoring in any number of data sources to determine the appropriate authentication context to issue.

The SAML and Liberty specifications are silent regarding an aspect of authentication contexts that has practical value to a business: what their ranking should be, or rather, which one is better. Therefore, in Symlabs Federated Identity Suite we chose not to hardwire any ranking, but instead allow for the insertion of customized business logic to evaluate the ranking.

Last (but not least), through the use of flexible business logic, customers can create an implementation that delivers complete control by defining contexts and assigning semantics of their own, in any way they please. Symlabs Federated Identity Suite provides this powerful capability by allowing configuration of custom contexts that can participate in the ranking and business rules just like any official context.

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.