Just Stop

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:

  1. email addresses are name-based.
  2. Names change (usually in the most personally sensitive situations, where they must change: marriage, divorce and witness protection or court ordered separation).
  3. Not everything that looks like an email address is a deliverable email address (e.g. userPrincipalName, eduPersonPrincipalName).
  4. If it looks like an email address you will be tempted to assume that it is an email address.
  5. You could be wrong – it might not really be an email address.
  6. Do you really need to know someone’s email address?
  7. Why do you need to know someone’s email address?
  8. Most people have multiple email addresses.
  9. Which one do you need to know?
  10. How are you going to make the person remember which one they used?
  11. What if they don’t know?
  12. 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:

  1. Employee ID (not SSN)
  2. Student ID (not SSN and not name-based)
  3. Identity Management System (IdMS – if they have one) surrogate key
  4. Unix UID (if the customer is using a centrally-managed UNIX-type system)
  5. 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)
  6. 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.

Oxytosin and the Economic Benefit of Trust Fabrics

The global higher education IT community is doing something pretty amazing. They’re weaving together a trust fabric to allow shared services via robust federated authentication and attribute-based authorization (see: InCommon, UK Access Federation, GakuNin, EduGAIN, REFEDS, many others).

At any scale, it’s hard to extend trust from “my tribe” to “your tribe”- but once we’ve done it, the return on the trust is almost magical. With federation in higher education, suddenly services and projects a school would be hard pressed to support on its own become easy to leverage.

So how does this scale beyond higher education? Trust is the basis for lowering barriers to collaboration and lubricating the machinery for an effective economy (See Paul Zak’s fascinating TED talk on Oxytosin). I think this suggests that higher education is once again leading the way in building a framework for increased global trust, global research collaboration and global wealth production.

There Are Still Frontiers

There are still frontiers out there, if you know where to look.

A friend of mine, who was doing fun pioneering work in computers and networks in the wild and wooly days of the 1980s and early 1990s lamented once, “I wish you had been around then, it was so different.  It wasn’t like now, now it’s a business.”

Although enterprise computing is now run like a business, there are still frontiers, there’s still room to explore if you look in the recesses of the IETF / ISOC repositories, Google mailing lists and GitHub, interesting people’s YouTube channels and Twitter feeds.

Take for example Moxie Marlinspike – he’s trying to solve a real problem with the current state of SSL and Certificate Authorities, and he’s doing amazing things there.

There are the tens of thousands of active participants in international higher education identity and access management, figuring out how to federate access to campus resources like wireless networks, web applications and research cyber infrastructure.  They are paving the way for a future when we don’t have to remember more than one password- or even any at all.

There are still frontiers at the fuzzy edge of the network, and I’m excited to see them and be able to participate in them, even just a little.

InCommon Silver With Active Directory Domain Services Cookbook Feature-Complete

For more than a year, I’ve been leading an effort within the Committee on Institutional Cooperation (CIC – the academic wing of the Big 10, plus The University of Chicago) and a number of other InCommon participants, to define an approach to mitigating risk within Active Directory Domain Services, with the goal of achieving InCommon Silver assurance. The work on that cookbook is now largely complete. You can take a look at it here: https://spaces.internet2.edu/x/w56KAQ

Whew.  That took a while to do.  I hope that at some point some school actually achieves Silver using it.

Rebuilding T-SQL Indexes From Powershell

Here is a Windows Powershell function I wrote to call a generic stored procedure that will rebuild all indexes in a database.  (I found the stored procedure here: http://www.wisesoft.co.uk/scripts/t-sql_defrag_indexes_for_database.aspx) This turns out to be extremely useful for rebuilding indexes on a SQL Server-based connected directory at the end of each run of a Microsoft Forefront Identity Manager (FIM) MA that has undergone a lot of changes.

PowerShell function:  

Function Run-RebuildIndexes

      $log.debug(“Run-RebuildIndexes for MA=”+$ma.MAName +” DBName=”+$DBName)
      $SqlConnection.ConnectionString =“Data Source=”+$SQLServerName+“;Initial Catalog=”+$DBName+“;Integrated Security=True”;
      $SqlCommand.CommandText =“DECLARE  @return_value int                                          EXEC  @return_value = [dbo].[USP_REBUILD_ALL_IDX]                                          SELECT      ‘Success’ = @return_value”;
      $SqlCommand.Connection =$SqlConnection;
      $SqlCommand.CommandType = [System.Data.CommandType]‘Text’;
      $SqlAdapter.SelectCommand =$SqlCommand;
      if ( $nRecs-gt 0 )
                  $log.Debug(“Index rebuild result code: “+$rec.Success);
T-SQL stored procedure:
USE [DBName]
/****** Object:  StoredProcedure [dbo].[USP_REBUILD_ALL_IDX]    Script Date: 01/05/2012 14:14:21 ******/
— =============================================
— Author:        <Nicholas Roy>
— Create date: <Jan 5, 2012>
— Description:   <Rebuild all indexes in database>
— =============================================
      — SET NOCOUNT ON added to prevent extra result sets from
      — interfering with SELECT statements.
      SELECT @SQL =(
      FROM sys.tables t
      JOIN sys.schemas s on t.schema_id = s.schema_id
      FOR XML PATH(),TYPE).value(‘.’,‘NVARCHAR(MAX)’)
      exec sp_executesql@SQL

Putting Two And Two Together

So in the course of my evening of NFC/ISO 14443 smartcard/platform/API “literature” review, I put Steve Yegge’s rant together with an analysis piece about what Google thinks about NFC, and came to an unfortunate conclusion.  Google’s lack of NFC APIs, combined with them being the current best hope for getting NFC-enabled, ostensibly open smartphones into the mainstream, does not bode well.  My project must be tempered with realism.

(Good) Middleware Takes Time

“The Golden Rule of Platforms, “Eat Your Own Dogfood”, can be rephrased as “Start with a Platform, and Then Use it for Everything.” You can’t just bolt it on later. Certainly not easily at any rate — ask anyone who worked on platformizing MS Office. Or anyone who worked on platformizing Amazon. If you delay it, it’ll be ten times as much work as just doing it correctly up front. You can’t cheat. You can’t have secret back doors for internal apps to get special priority access, not for ANY reason. You need to solve the hard problems up front.”  -Steve Yegge, from his now famous accidentally public-facing Google+ rant on platforms

For some time, I have argued that spending the time to do a good service-oriented architecture is the right thing to do, especially in the identity management space.  It takes a very long time to do this right, and the QA, health checks and iteration become more time-consuming than defining and writing the initial service.  The monitoring for a good SOA becomes the unit tests, mocks, etc, and you end up doing right by your customers by eating your own dogfood.  The problem is, in academic higher ed, a lot of time, there seems to be no extra time to spend.  You have to do what you can with the time and resources you have.  So you try to do the best job you can, and you try to use exiting service frameworks where you can, and make your own where none exist, if you can find the time to do it.  That’s one of the reasons I like working where I do- I think people get why services and platforms are good, which you might think is truly amazing to find in a state-funded higher ed institution.  The more amazing thing is that I think a lot of state-funded R1 universities get this, and they are getting it more all the time.  See: ShibbolethGrouper and COmanage.

It’s interesting that Google, Facebook, Amazon, Apple and even Microsoft seem to be doing “sexy” things that get a lot of attention.  But the academic research institutions are doing a ton of work here, too, and while it’s not glamorous, it’s changing the world for the better.

Weekend Identity/Convergence Stream-of-Consciousness

I’ve been wanting to get a Galaxy Nexus phone for a while- as soon as I found out it was coming to Verizon.  This summer I almost ditched Verizon for Sprint to get a Galaxy S 4G with an NFC chip in it, but held off because I knew this newer Nexus was just around the corner.  I want to mess around with the NFC feature and see if I can make it store X.509 certs and act as an ISO 14443 smart card for things like workstation logon and door access.  The secure element in the Galaxy Nexus is an NXP chip which supports a lot of different NFC protocols, but Google has been pretty open about their non-support for card emulation.  This means there’s not a built-in way to handle this stuff yet.  But then I found this: http://code.google.com/p/seek-for-android/


For a while I was hoping that InfoCard would be a champion for identity selection and user-centric identity.  Now I hope it’s smartphones.  We’ll see how well this turns out.  I’ll be happy if my wallet can go away at some point.  It would be great to have payment, drivers’ license, passport, work login/door credentials, etc, all on the phone.  Some people probably think that’s a terrible idea and maybe slightly Orwellian (Dvorak: http://www.pcmag.com/article2/0,2817,2395071,00.asp) but I think it just makes sense.  The secure elements in these phones truly are secure, until they aren’t any more.  By that time we’ll have other things to replace them, and probably lots of other things to worry about.