EASI ID (pt. 2)

Back in March, I posted EASI ID (pt 1.5), posting a question about who owns the rights to resources within a namespace, specifically email addresses.  The reason was to stimulate some braincells, about what could happen if users chose to protect personal content with a digital identity that they thought they owned, but which later they found out the didn’t (in this case their work email address).

Ariel Gordon, one of the rock stars on the Microsoft Identity Strategy team (along with Kim Cameron and others…), recently posted this comment:

Ariel Gordon said

August 7, 2009 at 2:34 pm e

Contoso owns the domain and any identifier in its realm.
Email addresses bear a claim of employment. I.e. my @contoso.com address shows (with a certain level of certainty) that I work for Contoso. Using this address after I leave the company is akin to keeping distributing business cards with the address on it.

Today, 99% websites leverage email providers’ infrastructure for user authentication: you type your email address as a login then create a password that can be reset/resend via email, effectively handing the keys to the account to anyone who controls the mailboxn including the new guy–Jerry Smith in your example.

Websites who implement authentication delegation (aka federation in the consumer sense of the term), could be informed by the IdP of user account deprovisionning and, as best practice, take action to close the account, prompt the user to create alternate credentials (if they have a fallback email address or phone #), etc.

Thoughts?
-Ariel.

I started to reply with a bit of the backstory in the comments, but figured I’d give this it’s own post, if for no other reason than (I think) it’s a fun look into some of the dynamics of digital identity…not to mention internal politics… So here is my response:

 

Hi Ariel!

Thanks for replying.  Yes, you’re correct, this is exactly what happens, and I agree with you.

The motivation for this post, was a series of conversations that I was in with an internal group here at Microsoft, about who "owned" the @microsoft.com namespace for user identities.  Historically, the internal identity management team has owned corp.microsoft.com, but the actual microsoft.com namespace was owned by the team that supports the www.microsoft.com website.  However, way back when, somebody in the Live ID team also decided that the microsoft.com namespace was theirs (in the Live ID sense)

It turns out, that today, there are approx. 2.5 million Windows Live ID’s in the @microsoft.com namespace.  Obviously we haven’t had that many employees.  But back in the day, there was a time when the Live ID team believed that @microsoft.com would be a good namespace for customers to use, similar to @hotmail.com or @live.com.  This isn’t really as crazy as it sounds, because it’s analogous to users creating a Yahoo ID in the @yahoo.com namespace. 

However many years later though, as we enter the age of federation, the challenge is that Microsoft Corporation uses @microsoft.com as our corporate namespace.  In contrast, Yahoo Corporation uses @yahoo-inc.com for their corporate email addresses.  So Yahoo can choose to give @yahoo.com to their customers, whereas Microsoft had a conflict.

This was a fun debate at the time, and ultimately we came to the decision that @microsoft.com is our corporate identity.  The question though, of what should come to those 2.5 million user ID’s.  Fortunately the Live ID team has the solution for this, and added a flag into the federation setup so that a company can choose to “evict on reserve” or “allow merge” of any existing users when they federate.

Allow Merge means that anyone with an existing user account in a namespace that’s federated, will have the option of associating their existing WLID with their new federated ID.  In Live ID speak, it means they keep the same PUID.  The result is that you keep anything you had access to, but you do so with your new corporate-account-backed, federated Live ID rather than your older, separate username/pw WLID.

Evict on reserve is just what it sounds like, where any user accounts which exist in a namespace when it’s reserved, will be moved into a “forced rename” state.  This means that the next time the user logs on with their separate user name and password, they will be forced to change their user name (keeping the same account/PUID) to a different email address, one which is hopefully their personal address.

For Microsoft employees, we chose evict-on-reserve, and are in the process of working through the details of implementation.  Our thinking behind this, is that even though they are in the @microsoft.com namespace, any existing accounts are all “personal use” accounts.  Therefore, we should protect the personal data, and have a user rename their account to a personal account.  When a user logs in with their “new” federated @microsoft.com account, they will be doing “business” work with an account that is backed by their corporate credentials (and which goes away when their employment ends).  And yes, we’re working with the Live ID team to get some controls put in place for companies that federate, so that they can limit where corporate backed WLID’s are used.

So that’s where we’re at.  Hopefully this gives other folks who are federating something to think about as well, as they integrate with service providers such as Live ID.

I’d love to hear what you, or anyone else thinks about these fun, “moving to the cloud” challenges!

~Brian

Facebook is going to allow user names on June 12th

If you use Facebook, you might notice a box when you log in that says beginning June 12th, Facebook will allow registration of user names.  If you “click here” to have them send more info, you’ll receive this in your registered email inbox:

Starting on Friday, June 12th, at 9:01pm, you’ll be able to choose a username for your Facebook account to easily direct friends, family, and coworkers to your profile.

To select your username, visit the link below after 9:01pm on June 12th:

http://www.facebook.com/username/

To learn more about usernames, visit the Help Center:

http://www.facebook.com/help.php?page=896

Thanks,

The Facebook Team

 

So what does this mean?  Well, for one thing, it means that if you’ve got a common name – or – if your like me, and you KNOW that there’s someone else on Facebook with the same name (since he and I are actually friends on Facebook), then it means that you want to “claim” your user name as soon as the application opens.

I did seen an interesting article here http://www.huffingtonpost.com/jonathan-handel/trademark-protection-and_b_213756.html about trademark registrations and how Facebook intends to handle squatters.  So don’t bother trying to register facebook.com/McDonalds, you won’t have it for long if you do. 

I like the very last part of that article though.  There is already a recommendation for what to do, if somebody maliciously claims not only your trademark, but also fills out the forms sufficiently such that you (the legitimate owner of the trademark) actually can’t use the automation to claim it back.

Oh how much fun Identity Management can be

Random port? I think not…

6 months ago – We’re in the process of federating with a new partner, and the link they send us to their federation server looked something like this:  https://federation.foo.com:9031/blah – notice the port 9031?

This seemed a little random, but not completely unusual since people tend to grab an available port when they want to host a test/beta site.

With a bit of troubleshooting, working with our proxy server team, etc… figured out that our proxy servers only allow SSL connectivity out to port 443, so the federation was broken.  A bit of back and forth with the partner, they moved to the standard SSL port, and everything worked great.

4 months ago – We’re in the process of federating with a new partner, and the link they send us to their federation server looked something like this:  https://federation.contoso.com:9031/blah

Us:  Hey, we’ve seen this before – we can only connect to port 443 for SSL sites, can you move your federation server to the standard port?
Reply:  Sure, done – check it now

And there was much rejoicing. yeah.

Rinse and repeat this a half a dozen times over the past few months, and we’re getting pretty good at recognizing the issue.  And since about 60% of our federation partners are using STS’s which are not ADFS/Geneva, this scenario is even more common.

The other day, while dancing this dance yet again, we did notice one thing though – It’s not a random port – it’s ALWAYS port 9031.  Not only that, but looking back, it’s always with partners who are using Ping Federate server.

A quick search for “9031” on the Ping website, finds that a lot of their sample code uses port 9031. 

Ah ha!  Now I get it.  It wasn’t random after all, but rather re-using the sample code to set up services.  Which is a great, so now we know that when we’re federating with a partner that’s using Ping Federate – be on the lookout for port 9031.

Collection agencies….

I have had a few discussions recently at work about ways to make things more convenient.  Either convenient for our users (cloud services), convenient for our customers (single sign on), etc… 

But a one-two punch hit me, when I just had 2 close friends – both of whom have been impacted by the financial mess – have their identity attacked because something that had built in security controls (checks) was made to be more convenient (by phone), and in the process all of the controls were removed so my friends were vulnerable.

Really, I call it fraud, or identity theft, or just plain robbery…  But in both cases, the banks say that there are no laws against this:

My friend lost her job, and fell behind on payments.  She owed $1100 for this months rent, $4400 to a creditor that by this point had gone to a collection agency, and some other bills (credit cards, gas, electricity, etc…).  Through creative budgeting and working with parents, friends, and anyone else, she scraped together $5000 that she could use. 

With the new money available, she came up with the following plan:

   $1100 for rent
      900 for the other bills
      500 to the collection agency
      The rest to be used for the following months rent, payments, etc…

She called the collection agency, and agreed to pay them $500 now, and then set up a payment plan for the rest of the money.  That’s where the first mistake happened:  They wanted the payment as a “check by phone”.  So she voided a check, gave them the info, etc…

The collection agency first attempted to clear the check for the full $4400.  Because the money was in the account, the check cleared – of course, this meant that she couldn’t pay any of the other bills, or her rent, etc…  And she had already tapped out her friends, parents, etc…

You can imagine that the calls to the collection agency were like:  “Sorry, sucks to be you – we’ve got our money now”

The bank was equally useless:  “You gave them a check by phone, the money was in the account, they cleared it…Sucks to be you”

This was just completely ridiculous, but it shows that in the absence of standards or protocols, there is no shortage of people that will offer things for the sake of “convenience” which blow the hell out of “security”.  If you have to write a check and sign it, then you fill in the amount, etc…  modification of that is check fraud.  But those security controls went out the window when banks allowed people to do “checks by phone”, and there is absolutely nothing to prevent unscrupulous people from raping your bank account if you give them the information.

The second case is similar, but with a slight twist

My friend has slowly but surely been paying off debts that were racked up over a period of time, and has been working through one of those debt consolidation management companies.  Since she wasn’t getting the resolution that she needed from the company, she took back the money that was in their escrow account and started working with the collection agency independently.

On the first phone call, she had an $7,000 debt and worked with the agency to negotiate down to where they would accept $4300.  Seems like a good deal, so again, check by phone for $4300.

A couple of days later, she received a notice from the collection agency, indicating that they “Had an agreement for an initial payment of $4300”.  In other words, the deal they made on the phone was a lie, instead of negotiating the total, they just wanted an initial payment and were going to keep going after her for the remaining balance.

Ahhh…but the check by phone hadn’t cleared yet.

So a quick call to the bank, a $28.00 stop payment charge, and there was a stop-payment for that check before it cleared.

Good right?

Not so much.  2 days later, $4300 was withdrawn from the account anyway, by check #1001 (not the check number she gave them).  A long, convoluted, multi-transfer call back with the bank this time, and they could see where the initial check number had attempted to clear, been rejected (the stop payment), and then the company had re-submitted another check by phone with the different check number and got the money.

After several days of arguing, it’s still unclear whether the bank is going to say “Sorry, sux to be you” or if they are actually going to help.  I’m not holding my breath.

So again, the safety features around checks – being numbered, signed, amounts written (twice) – are all placed into the trusting hands of the least trustworthy person (the merchant that wants your money), and there is remarkably little recourse.  I suppose you could go get a lawyer, etc…  But during that time the money is gone, life still needs to be lived, and a lawyer is going to take 30% of whatever you get back anyway (or some amount of payment)…

All for the sake of convenience (to whom?)

There are better ways, one of which I really like.  I’ve had a credit card with CitiBank since college.  And many years ago, they came up with this idea of virtual account numbers for your credit card.  You can go to their website (or they have a downloadable application), and if you want to make a purchase, you can get a one-time use credit card number (with expiration and CVC) for that one purchase.  I haven’t used it in a while, but IIRC you can even specify the amount of the purchase you’re going to make (which is really the protection).  This is great, because the security of a credit card is handing the piece of plastic with the signature on the back to the person behind the register.  With online purchases, you can’t do that, so instead lets take the things which you can control (amount of purchase, usefulness of the number after it’s been used properly) and control those instead.  Reasonable mitigations.

This is the type of control that we’re going to need if we want to protect our resources in a more “convenient” (read: Online) world.

Being Hacked is ok (if you’re paying for it)

There were many great speakers at TEC 2009 this year (and I was there too!), especially in the Federated Identity track.  One of the things that I was interesting, was during one of the sessions the speaker described many of the current non-federated authentication schemes that SaaS providers can use.  The implementations may have varied slightly, but they often amounted to “Give us your user name and password, and we’ll authenticate you across some out-of-band channel.”  The deployment of this service requires that extra channel for auth, sometimes being a VPN connection, or an LDAP service that the provider can authenticate against…things like that.

A comment was made, something about the security risk that this poses; after all, it IS by definition a “man in the middle attack.”  The next couple of minutes were spent blasting this type of ridiculous design (after all, this was the federation track) and how horrible this was and people would never let this type of set up occur at their company.

Of course, that’s probably not true at all, is it?  After all, every application outsourcing project I’ve worked on includes the “user SSO” line item, but nobody says what that has to be.  And the corporate security risk analysis has to outweigh the hard dollar cost savings that were driving the project to begin with, which is why I suspect that the typical CorpSec risk analysis always ends up somewhere in the Billions of dollars with a picture of the company going down in flames.  Yet even that’s not enough even enough to stop the project from moving forward, because at the end of the day, IT departments are often not empowered to say “No, you can’t do that”…rather…we end up saying, “This sucks, but here’s the best that we can do to make it work.”

And that is why, a man in the middle attack, even one with credential harvesting, is OK if the company is paying someone to do it (and saving real money in the process)

And it’s why now more than ever we need comprehensive federated authentication solutions, so we don’t have to get run over by these hacks.

EASI ID (pt 1.5)

Question for you

You’re Jon Smith, and you signed up for the TAA.COM (Totally Awesome App) application when you worked at Contoso, it was free and let you store all of your client data.  You signed up with the user name, JSmith@contoso.com.  Good thing too, because when you quit working at Contoso years ago, you took your clients with you.  Over the years, you either have never updated your login ID, or maybe the application won’t let you.

Now TAA.COM decides to break into the SaaS market by offering their totally awesome app to business customers, and Contoso signs up.  Who gets to have the JSmith@contoso.com user name, you (by virtue of being first), or Jerry Smith, the current JSmith@contoso.com who was hired after you left?

Even though Contoso has federated, single sign-on authentication – does it matter?

I guess another way to put this, is does an individual own the usage rights to their email address forever, or does the company own their namespace and all resources (ie. names) within it?  Worse case, what happens if Jerry signs in and see’s Jon’s information?

EASI ID’s (part 1)

When you log into a website which you use for personal stuff, for example using your Google or Windows Live ID; or even better, logging into Facebook or Myspace.  What do you use for a user name?

Intuitively I’ve known this for a while, but I have recently been having a ton of discussions about EASI logins, or Email As Sign In.  This makes sense, when you register at a website, they ask you for your email address, and that’s what you’re “user name” becomes.  Simple, easy to remember.

There are of course, a couple of flavors to this.  In the case of Facebook for example, you must “verify” your email address.  When you sign up, they send you an email, you click on it (proving that you have access to the email address), and then you get in.  Of course, not all services require verification, and for those, you can enter any email address you like.  Just ask Robert Schuler if he thinks verification is necessary when creating an online identity!

I just got back from TEC 2009, an excellent conference that I have the privilege of speaking at, where I always get into great conversations with a ton of incredibly smart folks.  Since I’ve been in this “EASI/Online/Enterprise Identity Convergence” kick lately, and since I was surrounded by a bunch of identity management professionals, i asked whether anyone had experienced issues with using their work email address for EASI logins to personal websites.  In general, the answers were either, ‘no, because I’ve worked at the same company for years and consider my work email my “primary” address’ – or – ‘Yeah, and it was the biggest PITA and I hope to never have to do that again’

The one answer that surprised me though, was one person who actually said that she’d worked at a company before, where they had hired a new person.  And they had actually provisioned this person a new account 3 weeks before the he was scheduled to start, just so he’d have that new email address and could migrate all of his online service accounts to it.  I’m honestly not entirely certain how this was a good idea, but alas we are all IT folks, and have to do what we’re told.  Kind of crazy though.

More to come on EASI ID’s, and some of the quirks we’re seeing as more and more enterprise services are moved to the cloud.

Security Evolution

My buddy Dan who used to work in Microsoft IT Security, and is now working over in the Information Protection product group (mostly known for RMS) wrote a doc back in 2005 on the evolution of security in the enterprise.  He had been asked for the doc so many times that he posted it to a blog about a year ago, but whenever I start thinking hard about federation, application authorization, claims based identity, and all of the other “fun” topics which make my days interesting, I occasionally need to go back and remember that being in IT is as much about where we are “at”, as where we are “going”.

This is the main graphic from the document:

From what I can tell, we are somewhere around the little tick mark that separate “near term” from “mid term”.  Things like IPSec, NAP, Windows Firewall, etc… have all done a pretty good job of moving the security from the network boundary to the host.  With Windows Server 2008 R2, Microsoft has finally productized Direct Access – which I can now admit that I have been happily been using for 2-3 years now, and probably couldn’t live without.

But when I think of the challenges in the identity space around federation, the separation between personal and business data, and how we’re going to protect the enterprise when everything is in the cloud – I can’t help but to think that maybe the arc on that “data” line is (unfortunately) a little too steep.  As hard as we try internally, the adoption around data protection is still far below what we need it to be.

Progress takes time, and I like working with the IPC team as they have a great things planned for the future.  Like everyone else though, it’s hard for me to “wait for the next release” to get the features I need.

Business Data and Personal Data (pot-A-to, pot-AH-to?)

How do you tell the difference between “business data” and “personal data”?  Since we’ve been diving head first into this whole federated identity thing, it’s turning out to be pretty darn important.

The best that I can come up with at this point, is the following guideline:

If you’re supposed to have access to a piece of information after you quit or are fired, then it’s personal

Man, I wish life were only that simple.  Here are a couple of examples of decisions from real life ADFS federations that we’ve set up between Microsoft and some of our business partners.

Microsoft employees in the US (and elsewhere) are provided medical and other types of insurance as part of their benefits package.  The HR team wants to leverage a vendor to manage most of the benefits, and provide SSO for employee’s.

Is this business or personal data?

By my definition above, this is pretty obviously business data.  Ah, however midway through the project, there was another requirement thrown out.  (I’m obviously stereotyping here, but for fun…)  It seems that a large number of Microsoft employees are married men, and some large percentage don’t want to manage anything remotely having to do with their family or finances, most likely because their wives won’t allow them to.  So during this project, we now need to allow an employee to provide access to the benefits portal for their spouse.

The solution?  Employee uses ADFS to sign into the portal, and then they can specify WLID’s that are allowed to log in and manage them as well.

Not bad, but the implementation went sideways.  What we’ve got now, is a case where users who are logging in from corpnet have to use ADFS, however ALL USERS that log in from the internet use WLID’s.

Operationally, this is really bad, because the only way you can tell from the internet, where a user is coming from, is by IP address – so if we add a new proxy server IP, we will have transient auth failures. 

From an IDM standpoint, the goal was that when a user was terminated, they lost access to the site.  They only have access because of their relationship with Microsoft (ie. it’s business data), and they lose access to it when they are terminated.  However instead of enforcing this with auth, we now have to rely on the HR, out-of-band, feed to notify the vendor of an employee termination.

Another example, occurred this past January:

In December, Microsoft and our payroll vendor federated an application such that MS employees in the US could gain access to their W-2’s (US tax documents) online, by signing into the application using ADFS.

It’s easy to interpret a W-2 as being business data, after all, it’s essentially a summary of your annual payroll, but it was this case that helped by boil me definition down to what I wrote above.

You see, in December we sent out this e-mail, we had a significant number of employees sign up for online W-2’s, which as part of the process they agreed not to need paper W-2’s to be mailed to them.  They would just print them out.

However in January of this year, Microsoft was one of several companies that unfortunately had to cut costs and lay people off.  Part of this process, was that the impacted users had their accounts disabled.

So to summarize the insult to injury:

-  A user signs up for online W-2’s
-  They are layed off
- And the account they need to use to access their W-2’s is disabled

This is a pretty clear case where we should have used some form of public auth provider like Windows Live ID or similar – essentially allowing users to get their W-2’s using their personal ID instead of tying the access to their business ID.

However you have to stop and ask yourself:  “If an employee accessing their W-2 is really a person accessing personal information, then what is an HR analyst that’s providing support, who has to access MY w-2 to give me the help I need?  Surely we could all agree, that this is a case of a business identity accessing business information!”

Identity Huh?

I’ve got a Windows Live ID.  I tried to re-activate the Hotmail mailbox that would go with it.  The activation errors out, and “click here to go to the solutions center”

When I get to the solutions center, I get a page with this message:

You have successfully logged in with Windows Live™ ID.

However, your Windows Live ID account is not currently linked to a Hotmail Online Solution Center account.

Create a Hotmail Online Solution Center account.
Please create one now by clicking the Create Account button

 

Seriously?  I’m logged in, but not logged in? 

As an identity management oriented type of guy…we need to do A LOT better than this.