At Synergy Berlin 2010 we talked a bit about Bring Your Own Identity (BYOI) in our CTO Crystal Ball session. Here is some background material in the form of a Q&A. I hope it will help explain some of the issues surrounding BYOI in plain terms most of us can understand.

What is BYOI?

The idea is that a user can bring the credentials for one of the services they use in their private consumer lives (say their Hotmail or Gmail account credentials) and use them as a basis to gain access to the corporate resources they need to carry out their jobs.

Why do people want BYOI?

BYOI is an extension of the idea that corporate workers bring their own computer and mobile networked devices to access work related resources. If I can bring my own device and use my own broadband wireless network, why can I not use my own MobileMe, Windows Live, Facebook, Gmail, or similar identity?

Maintaining a record of certified users, managing the authentication of these users, and safeguarding all the personal data associated with identification processes can be a complex and costly business. As the enterprise seeks ways to reduce cost, outsourcing a part of identity management to a service provider seems an attractive possibility. As a service provider, being able to leverage the identity management system of a large established player removes a significant barrier to entry and simplifies on-going identity management.

Why is BYOI relevant to Citrix?

BYOI is a direct consequence of user demands for a simplified and more consumerized approach to the delivery of IT services. Citrix is expanding its application and desktop delivery infrastructure to cover web and SaaS applications and resources. We are making sure that we can respond to demands for BYOI by ensuring our systems include appropriate authentication, access control, and auditing facilities and by adopting disciplined design and standardization across our product range.

The bottom line

Before we answer more questions, here are some high level points to remember

1.       The main driver for BYOI is not cost but agility.

2.       The main obstacles to adoption of BYOI include risk aversion and lack of trust.

3.       Some industry verticals will adopt BYOI much quicker, some won’t at all.

4.       Diverse technologies that support BYOI exist, the challenge is integration.

How does BYOI work and what are the pitfalls?

To get a handle on this question, we need to take a step back and examine how authentication and access control systems work in more general terms. Let’s try and keep it as simple and high level as possible.

How do you “use an identity” to obtain a service?

Typically the identity itself is not used directly to obtain access to a resource or service. Instead you use a claim to identity issued by some trusted party. You will only be given such a claim if you are able to prove that you are who you say you are, via a process called authentication. A claim can take many forms. Depending on implementation it may be called a certificate, an assertion, a cookie, etc.

Who are the trusted party and what other parties involved?

There are typically three parties involved in any authentication and access control scheme (including BYOI), as shown in diagram:

Figure 1: The parties in an authentication and access control system.

  1. The User who is attempting to access a resource, such as a desktop, an application, a file, a web page,  or a service;
  2. A Resource Provider (also called theRelying Party) who controls access to the resource;
  3. An Identity Provider (also called the Issuing Party) who is able to certify the identity of a user, and who can issue evidence to this effect (authentication). 

In typical usage, the user obtains evidence regarding their identity from the Identity Provider and provides this evidence to the Resource Provider. When the Resource Provider is satisfied that the evidence is genuine, access can be granted to the requested resource.

For the system to work, the Resource Provider needs to be able to trust that the Identity Provider does its job properly. There must be a trust relationship between the two. All parties also need to be satisfied that evidence regarding identity cannot be forged or tampered with. A variety of security technologies, including encryption, are employed to ensure the right safeguards are in place. Any encryption technologies in use also rely on formal trust relationships between the parties, such as the use of mutual SSL certificates.

There are many possible ways in which messages can be exchanged between the parties; each is usually referred to as an authentication protocol. Whist conceptually simple, design and implementation of secure authentication protocols can be highly complex. This is a very good reason for adopting well established open standards that will have been properly and publicly scrutinized. Rolling your own is simply a bad idea.

What about BYOI then?

In a typical enterprise system there is one Identity Provider, typically controlled and managed by the corporate IT department.  A common implementation of an Identity Provider in enterprises is Microsoft’s Active Directory.  Since the Resource Provider is also owned and controlled by the enterprise IT department, issues of trust between the two are usually implicit in the system design. This implicit trust simplifies identity usage within the enterprise, but greatly complicates usage of identities that come from outside the enterprise, such as those of contractors, suppliers and customers.


Figure 2: In a BYOI system, the user selects an identity provider outside the enterprise

In a BYOI system, the user is able to choose his or her Identity Provider. Consumerization of IT leads users to choose Identity Providers that typically live outside the enterprise. Of course, the Resource Provider (enterprise IT) still need to trust the Identity Provider that the user has chosen.  It is easy to see how enterprise IT may object to users who want to use Facebook as their Identity Provider.

Who is going to issue identities?

This is the big question. And it is a matter of trust and convenience.

From the Resource Providers’ perspective, each an every one of the Identity Providers that a user is able to choose must be trusted. For this reason, an enterprise IT department will at best provide a list of trusted Identity Providers from which its users may choose.

From the users’ perspective it is a matter of convenience to be able to use one of their established identities to access work resources. The choice will always be restricted to the Identity Providers trusted by the Resource Provider, but at least there will be a choice.

What is the basis of this trust?

To obtain an assertion of your identity in the physical world, such as a Driver’s License, you must present proof that you are you.  Trust factors such as a birth certificate, a utility bill showing current address, and a social security or national ID number must be presented.  A Driver’s License is considered a root of trust for operating a vehicle, travelling via air, obtaining access to controlled facilities and for other expressions of identity, in part due to the physical proof of identity required to obtain one.   There are situations where a Driver’s License is insufficient though, and a passport, specific physical ID card or biometrics is required for further identification.  These additional factors are required to manage risk to the Resource Provider.

To obtain an identity with most online services, you simply choose an identifier of your selection, determine a password which may or may not meet complexity requirements, and often present an email address that likely did not require any meaningful validation to establish. Basing a root of trust on such un-validated factors represents excessive risk, and is generally not considered acceptable to a typical enterprise.

A formal process exists today for issuing SSL Certificates that may parallel the creation of secure online identities in the future.

What if there is insufficient trust?

The motivation of the identity provider is a critical consideration in deciding trust. If the motivation is to just gather up users, having low barrier to entry implies that the provider would be a poor choice.

If a Resource Provider has insufficient trust in an Identity Providers processes and the identityfactors asserted by a user, then further checks can be carried out via re-authentication with an Identity Provider that is sufficiently trusted. This can obviously present obstacles to single sign-on requirements.

A visa is an example of evidence of the extra checks carried out in cases where a passport alone provides insufficient proof of identity.

Can enterprise IT save money by outsourcing identity management?

Although it looks promising, savings could be a false hope today. Authentication (establishing an identity) is one of the three A’s. The other two are Authorization (access control) and Audit. By outsourcing Authentication, the enterprise needs to place much greater emphasis on Authorization and Audit. So, where the cost for one goes down, the cost for the other two are likely to go up. It is not clear whether this can be a zero sum game at this stage.

Is there a need for a new legal framework to support trust relationships?

The legal authority to issue identities will most likely be derived from contractual relationships that are formed between identity providers and consumers (users).  Government will also likely provide a means to further align physical and online identities.

The legal framework that supports the trust relationship between the parties will also need to be in the form of a contract.

How is user privacy handled?

Identity Providers will need to abide by all applicable privacy legislation within the jurisdiction in which they operate.  They will need to act appropriately to attract end users to register with them. Service providers will also prefer to work with trusted Identity Providers. So, there is a market-like mechanism that will in time promote “good” Identity Providers over inferior ones. There has been talk of using a reputation score, to help end users select identity providers.

What about anonymity?

There are situations in which a user might like to access a service without revealing exactly who they are (i.e. preserving anonymity). This can be done by making sure that, once a user has been authenticated, the certificate or token that will be used to access a resource or service holds no specific data on the end-user. The Resource Provider needs to be able to allow access on the strength of a statement from an Identity Provider such as “this user has been authenticated by me, please trust her”. Please note that the Resource Provider may choose to provide a degraded level of service to anonymous users, to both reduce risk and to encourage these users to express their formal identity. There are parallels to loyalty programs, discounts and targeted services in this model.

What about the strength of an identity?

The stronger the factors that comprise an identity, the more we can trust that identity. There are two parts to the assessment of strength: the rigor of the authentication authority and extent to which the identity, once provided, can be forged.

The authentication authority encompasses the processes, people and the technologies used to create the identity. This includes the process of authentication itself: the process of establishing that someone is who they say they are.

There are many ways to authenticate. Electronic authentication may be supported by PIN; password; soft crypto tokens such as digital certificates; one time passwords (such as RSA SecureId), hardware crypto tokens (such as SmartCard), or a combination of these. More recently we have seen various biometric mechanisms added to this list. NIST have set out a scale of four levels that can be used to determine what type of electronic authentication provides low, moderate or high protection (see NIST SP 800-63).

The electronic identity itself (the claim) can also take different forms. For example, it could be a simple cookie, as used in web browsers, or it could be a more elaborate structure, such as SAML assertion. Various techniques are employed to make it hard for attackers to forge, copy, replay, or otherwise tamper with these electronic identities. All these techniques are based in cryptography.

How do we detect that an identity has been forged?

Electronic identities are typically signed and/or encrypted in such a way that a Resource Provider can spot whether it has been tampered with, or whether it is being used out of context (replay). The detection mechanism relies on secrets which are shared between the Identity Provider and the Resource Provider. The shared secret is part of the trust relationship between the two parties.

How do we revoke an identity, once it has been issued?

Electronic identities often carry a timestamp or an expiry date. If an identity needs to be revoked before the expiry date, then all that can be done is to warn all Resource Providers that the identity has been revoked. The Resource Providers can then reject any requests associated with that identity.

What about multiple identities?

!B8.jpg|align=right!The basis of identity is expressing “who you are”. Note that most individuals today have multiple identities in their personal and professional lives, depending on their role, information they’re willing to share, and in their relationships to others.  A key point is that your base identity at MyCitrite and on Facebook need not be different (you are you, after all), but how you express that identity to these services will undoubtedly be different.

How do we link identities?

Many users have multiple identities.   These identities may be based on a single factor, but will provide additional information necessary to express the identity to prove role, authorization for purpose, or to maintain privacy.  Much as there are multiple expressions of identity in the physical world (Driver’s License, passport, that you are a member of an industry group, expression that you are a child’s mother/father, etc.) there will be multiple expressions of identity in IT systems and in the cloud.

Identities should be linked via a profile selected by the user.  When at work, a user can express that he’s identified as a UK Citizen, as a member of Citrix Labs and as a member of the CTO Office.  That user will likely not choose to express that he’s a member of an airline loyalty scheme or a stores frequent buyer’s club while at work.

How is BYOI different from federation?

In the recent past, IT departments tended to the paranoid and only trust identities they created themselves. With federationthey started to relax a bit. They became selective about who they trust: perhaps a specific partner in the supply chain, or someone who had signed up for Microsoft Passport.  The BYOI movement is really the next step. In response to consumerization, IT further relaxes its stance, and increases the number of trusted Identity Providers to include some from consumer space.

Federation and BYOI use similar underlying technologies for implementation.

Where can I find out more?

A Google search reveals that there is very little material on Bring Your Own Identity available. There is a huge amount of material available on security, identity, authentication, access control, audit, federation, and so forth. Much of it is written by experts for other experts. And much of it focuses on specific use cases, protocols, designs, or systems. Such material is not always easy to understand, and this prompted me to write this hopefully simple high level explanation.