My new pet peeve is cloud service providers who assume that they can and should use email address as a primary key for customer identities. This is a terrible idea for a large number of reasons. Here are some:
- email addresses are name-based.
- Names change (usually in the most personally sensitive situations, where they must change: marriage, divorce and witness protection or court ordered separation).
- Not everything that looks like an email address is a deliverable email address (e.g. userPrincipalName, eduPersonPrincipalName).
- If it looks like an email address you will be tempted to assume that it is an email address.
- You could be wrong – it might not really be an email address.
- Do you really need to know someone’s email address?
- Why do you need to know someone’s email address?
- Most people have multiple email addresses.
- Which one do you need to know?
- How are you going to make the person remember which one they used?
- What if they don’t know?
- What if they leave the {school, business, non-profit, government, etc} where they had their email account? Most best practices require deprovisioning of email for people who don’t {attend, work at} that place any longer.
The worst case scenario is that you, as a cloud service provider, have not been clear with your customer about your use of primary keys for identity, and specifically your use of email address as a primary key. The customer will then blindly deliver this to you and when customer identities’ email addresses change, someone else could end up with access to protected resources that should be owned by a different person.
Many small customers (likely the customers small enough to be looking for your cloud service in the first place) are not in a position to think about the security implications of this use. You should do that thinking for them, and bring them up-to-speed with the problems and pitfalls associated with using email address as a key. Sure, since most people have an email address, it’s a convenient piece of information that you can additionally use for delivery of things like password reset requests, confirmations and workflow messages. On the other hand, you can use other things (that don’t change and aren’t re-assignable to other people) as a shared primary key, and still ask for email address for use in sending email.
I have seen a large number of cloud service providers ask for email address as an identity attribute and not disclose its use as a key- this is the worst of all possible situations, because you are making assumptions about the nature of the customer’s email address that aren’t true, and you aren’t allowing them the opportunity to understand that because of lack of disclosure. I’m not a lawyer, but lack of disclosure of this kind of thing, leading to an unintended release of information via change of email address (situations in which someone else gets a previously used email address do happen) seems to open the door to legal action.
An ideal solution on the part of a cloud service is to make the primary key for identity very flexible (very long max length, any format alpha, numeric, etc). You should then develop an interview process that you use to find out what types of keys your customer can provide, and be able to map one or more of them into the key field in your service. Use a surrogate key within the service that’s hidden from the customer, and expose an API that allows the customer to update their users’ identity keys if necessary. Some suggestions for things that might make good keys:
- Employee ID (not SSN)
- Student ID (not SSN and not name-based)
- Identity Management System (IdMS – if they have one) surrogate key
- Unix UID (if the customer is using a centrally-managed UNIX-type system)
- Network ID (if it doesn’t change- ask the customer if they do. If the customer wants to use this, allow them to rename via an API)
- Scoped Network ID (scoped to the customer’s DNS domain name- ask the customer if these change, don’t use if they do, or allow renames via an API)
Cloud service providers: please stop asking your customers for email address as a shared primary key, and work to educate your customers on the danger of using email address as a key for access control.