Some time ago, in the wake of Wired journalist Mat Honan’s story of his account compromise (“How Apple and Amazon Security Flaws Led to My Epic Hacking”), I wrote about BYOI – Bring Your Own Identity – and how “In the enterprise, there’s even less reason to support today’s BYOI.” Some time before that, my colleague Martin Kuppinger had also addressed this issue (“Bring Your Own Identity? Yes. And No”), dismissing the BYOI idea as simply a small piece of a much larger system.
But I think we need to re-address this issue.
First, the term “BYOI” as it’s commonly used is misleading. It’s not your “Identity” you bring with you (everyone brings their own identity wherever they go), but a third party authentication that you bring to the table such as Facebook, Apple, Google, Amazon, etc. ( generally referred to as “social” logins) as well as other third party systems (government eID, healthcare identities, etc.). So let’s be sure to keep that context in mind.
Likewise, from the Enterprise’s point of view, there’s the question of who is bringing this third party AuthN to the table: an employee, contractor, vendor, client, partner, customer – or a visitor who might potentially fill one of these roles. Each of these roles has different requirements for authentication, each will look for different authorization, so each will be scrutinized differently by whatever passes as our Risk-Based Access Control (Risk-BAC) system. And make no mistake about it, we all (that is, our organizations) have a Risk-BAC system. It might be highly sophisticated, automated and dynamic or be a simple, static, implemented-by-hand system based on little more than a username/password combination for access (just because it’s high risk doesn’t remove the Risk-based facet of the system).
For visitors who may or may not be potential vendors, clients or employees the use of a social login is probably sufficient. We want these people to be able to access the resources they need with a minimum of fuss, but with a certain amount of information collected (name, email, physical address, age, and possibly other details). Asking the person to fill out a long form just to be able to view job openings or download marketing materials is going to turn off some otherwise desirable potential employees or customers. Fortunately, we can use the API (also called the “graph matrix”) made available by the social login provider to gather this information by simply asking the person for their approval. So, yes, BYOI works in this case, and works better than creating our own authentication system for this class of users. However, a difficulty could arise when this initial contact is then extended to a full-scale client (or vendor or employee) account – how do we tie together the initial information collected with this new higher value account?
For existing vendors, partners, suppliers and others, whose organization has a current relationship with our organization, the best result would come through federated login. That is, the person would login to their own organization’s system and we would accept that the person is an authorized representative of that organization. We really don’t need any other information about them. We’ve previously negotiated the authorizations that the user would have, which could be adjusted based on the information sent along with the federation credentials. For example, a large supplier might have multiple people needing access to our inventory of various items and would send along qualifying information so that our system would give the correct authorization for that inventory. All the user account maintenance is done by our federation partner, so there’s a sense that the data quality is better than if we tried to maintain it in our system. Using a social BYOI login could be disastrous as we’d have no way of knowing if the person was still employed by the partner.
Then there are the cases of employees and contractors. First we’ll divide contractors into two groups – independent, individual contractors and those working for (or with) a contracted agency.
Those people under contract to a third party agency, who do work for us under the control of the agency, are probably best handled as with other partners – by federation. The situation is a bit different as we’d probably need to adjust authorizations for each individual depending on the work they were doing but it’s also probably best that we let the contracting agency handle the initial authorization especially as it’s that agency’s HR department who would hold all of the individual’s relevant identity data. Of course, should that contractor become a regular employee we would also be faced with converting any data collected about that person from the federated system into identity data within our enterprise system.
For those contractors who are directly contracted by our organization – and not by way of a third party agency – we should use the same controls we would for employees. Generally, the only difference is in the tax status of the employee or the legal status (e.g., “employment at will” statutes), which from our perspective (Identity and Security) are irrelevant.
These are the ones that need to have individual accounts within our enterprise. These are the people who we need to login directly using the credentials we provide. These are the ones we need to scrutinize most, using multi-factor authorization when our Risk-Based systems suggest that we do. These are also the individuals who should be subjected to the most rigorous identity validation when they are first enrolled in our system, something the HR department should handle. By no stretch of the imagination should we ever consider using a social “BYOI” login for this people.
BYOI – especially the case for social logins - by its very nature has a low level of assurance for identity when compared to enterprise controlled systems (all else being equal). It’s useful for low value transactions but – at least as it’s constituted today – should give security personnel nightmares if ever used for access to the organization’s valuable resources.
So to the question “does BYOI have a place in the enterprise?” we can answer with a qualified yes, but also a qualified no. The Information Risk & Security Summit 2013, coming up in Frankfurt Nov 27-28 will go into BYOI on much more detail. You should register now to attend.