BPuhl’s Blog

A little bit of everything without actually being much of anything

Archive for the ‘InfoCards’ Category

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

Posted by BPuhl on March 27, 2009

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.

Posted in ADFS, Digital Identity, Identity and Access, InfoCards, Random Tecnical Stuff, Rants | Leave a Comment »

EASI ID (pt 1.5)

Posted by BPuhl on March 26, 2009

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?

Posted in ADFS, Digital Identity, Identity and Access, InfoCards, Random Tecnical Stuff | 4 Comments »

More Cardspace in the Enterprise

Posted by BPuhl on March 15, 2008

So it’s been brought to my attention, that there is a very important distinction which I should probably make about my views of Cardspace in the enterprise.  That distinction is the difference between Cardspace as a user interface – and Cardspace as the underlying infrastructure for performing claims based authentication.

The basic reason why I’m hesitant about Cardspace in the enteprise, is actually because I LOVE the idea of having my users perform claims based authentication and authorization…but I can’t fathom the idea that people are going to keep getting these UI pop-ups and having to pick the same card over and over again throughout the day as they are trying to do their job.  Even having to click it once or twice per day is too much in my opinion.

Since we already know that Cardspace will show you all cards which meet the criteria, as an enterprise administrator, I’d like to say that if there is only a single card which meets the relying parties criteria – THEN USE IT!  Don’t pop the UI, just go ahead and send the card, and have fun with that!

Yes, I realize that this violates numerous basic principles of user centric identity, however those principles that it violates are based on the idea that the person owns the digital identity.  In a company, the enterprise owns the identities, and issues them to individuals for use on behalf of the enterprise.  So we don’t really need (or in many cases want) the “transparency” or to provide the ability for a user to decline to send claims info, because that would distract them from the primary mission that we’ve issued the identity for to begin with – to do their jobs.  It’s not as though an HR analyst would make the decision, “You know, I don’t think I want this application to know my employee ID number, so I’m going to decline to authenticate to it.”  Ok, then what are you going to do, since accessing the application is a core part of your job, and the enterprise had determined (meaning, the app dev’s, security, IT, etc…) that the data was needed?

So don’t get me wrong, I love “claims based authentication and authorization”, and I firmly believe that Cardspace and Infocards have a HUGE value in the consumer space, anti-phishing, etc…  But I would love to see either more granular policies available to administrators over the user interface, so that we could use the cardspace plumbing while intelligently presenting the UI only when it was necessary.

Posted in Active Directory, ADFS, Digital Identity, Identity and Access, InfoCards, Random Tecnical Stuff | 2 Comments »

InfoCards in the Enterprise

Posted by BPuhl on January 15, 2008

Recurring theme lately around the office – When are we going to start using InfoCards and Cardspace internally?  In fact, I was fortunate enough to be part of a conversation recently with several of the smart guys in the MSIT Security team, and although we didn’t come up with anything hard or fast – Here is where I’ll give you “my take” on when we’re going to use InfoCards and Cardspace internally.

Important Disclaimer – Discussions are great for helping you articulate your thoughts, but all opinions in this blog are my own.   Also important to note, that most of the InfoCard and CardSpace discussions are around solving the consumer identity problem.  This is a huge problem to be sure, but I’m an enterprise IT guy – so it’s not the problem which I’m focused on every day.  I care about my enterprise identity management issues.

First – a bit of terminology clarification:

 

CardSpace – This is the identity selector.  It’s included in Windows Vista, and available for Windows XP, but in short, it’s the “secure desktop” (you know, the bright colorful part of your screen when everything else goes greyish/black)…..(no, not a crash! smart alex, those are blue!)….  The purpose of CardSpace though, is only to allow you to select InfoCards.

 

InfoCards – These are the things you select in CardSpace (Ha! Bet you didn’t see THAT coming!).  Each InfoCard represents some set of bits of information about you that you want to submit to a website.  There are a couple of flavors, self issued, and managed InfoCards.

 

Self-Issued – Pop open a browser, and see how the Windows Live, Yahoo, and Google toolbars (I’m sure some of you have all 3 installed) have the “Auto Fill” button?  Yeah, that’s pretty much the idea behind a self-issued card.  Of course there’s some more, combined with identity selector you get some anti-phishing help, so you don’t accidentally auto-fill your paypal user name and password into the paypa1.com website, but conceptually, it’s auto-fill + anti-phishing.  These cards could be useful as replacement for the Post-It notes below your keyboard, which have username and passwords written on them for all the websites you frequent.

 

Managed – These are cards are actually issued by a server (as opposed to being self-generated), and are more likely to be used to pass information which is stored in a centralized identity store, and vouched for (ie. signed), by that store.  Think for a moment, an application which only trusts information about your user account which came from Active Directory.  A token server could issue you a managed card, which corresponds to your AD account, and whenever you access the application and select the card, then the requested attributes from AD are read and placed into the token.

So if the question is really, when are we going to use InfoCards and CardSpace internally at Microsoft, I think there’s a good chance to say that we wouldn’t.  Now, this doesn’t mean that we won’t, just that the problem which they solve is actually a symptom of a larger problem, which has solutions – albeit, more complex ones. 

Let’s take a look at the scenario’s in which these technologies would provide a good value to our business:

Single Sign-on (Internal) - The purpose of an identity selector, is to select an identity.  Ok.  Probably could have been named a bit more descriptively, but we’ll go with it.  How many identities do you have in an enterprise?  Well, ideally, you want to have one – and that one would allow you to access everything that you need.  Ok sure, but we all know that isn’t how most enterprises work, instead they have many systems, each one with it’s own identity store.  Well, as I’ve said before, if you have an identity store, you immediately get a provisioning problem.  So there are actually 2 ways to solve this problem then – First, you can make it very easy for users to manage their 21 user names and passwords (or whatever it is), and provide them a pretty UI for swapping into and out of applications.  CardSpace fits this bill nicely.  It’s not really SSO, because I count having to select a card as a “sign-on”, but it’s definitely “easier sign-on”, that’s for sure.

 

Single Sign-on (External) – Isn’t this what federation is all about?  Well, sort of, but the fact is that there are a lot of partners which we can’t federate with.  However, if they were to issue managed InfoCards, or even allow our users to register self-issued InfoCards as their authentication mechanism, then it would help relieve the Post-It note under the keyboard problem.   Still though, this means that your partners are going to need to maintain their own identity stores.  InfoCards will help ease the user pain, but the businesses (and IT guys – like me) still have to deal with the provisioning problems, data consistency issues, and security concerns of allowing a partner to have all of this information.  The better solution would be to federate with our partners, to allow our users to access with their corporate credentials, no UI prompt, “it just worked”.

 

Role Transitions – Internally, this is something which we have only started to think through, so I’ll describe what we’re thinking – and leave the question of whether or not it’s worth it for later:  If you’re an administrator of an enterprise application, then there is also a reasonable possibility that you are a user of that application as well.  If this is the case, then is there a need/desire, for you to sometimes access the application as a user, and sometimes as an administrator?  Usually, the way that you see this, is that an administrator has the same menu options as a user, plus additional ones.  Is there any reason why this is bad?  To have the administrator role separated from the user role, would be much easier in a CardSpace world because transitioning from user to administrator and back could be done much easier.  But that seems like a lot of work, and it’s never been a requirement to date (at least not for application admins).

There may even be more places where InfoCards and CardSpace can fit into an enterprise.  These are the ones which I have come up with so far.  The pattern which seems to be showing though, is that if you can’t fix your “big” identity management problems, then you can use InfoCards to ease the user experience of them.

Posted in ADFS, Identity and Access, InfoCards | Leave a Comment »

ADFS and Liability Continued…

Posted by BPuhl on October 3, 2006

hmm…let’s see…I wrote a blog, Pam left a comment, I replied to her comment with another blog, and so (if you haven’t seen it yet) Pam posted her own blog entry here…  This is actually kind of fun!

You should read (all of) her posts anyways, but to save some screen flipping here’s the meat of it:

…When I read this, I felt like jumping up and down like the goody-two-shoes in the second row, me me me me oh I know the answer pick me!!!

If they were to use an Information Card for the active confirmation prior to a user making changes, users wouldn’t need to remember a password at all. You would get the impediment of requiring credentials, without the support burden attached to maintenance of a rarely-used password. Alternatively, if you felt the need to have a password, you could require a managed information card. In that case, the user would be authenticating to the home IdP instead of to the outside application, taking the password management burden off of your partner and consolidating password use to a single centralized source that would theoretically be much more commonly used, and therefore less likely to require frequent recovery. Not to mention that the Enterprise could audit use of the managed infocard in this context.

This seems to me to be a perfect scenario to envision a hybrid passive/active federation combination instead of passive federation for 85% of user activity, and partner-managed password authentication for the remaining 15%. Yes? If so, it just goes to show that the scenarios are out there, and for more than just the eBusiness world.

Brian, what do you think?

So…let’s see…What do I think? 

I don’t think the problem is in the way that the credentials are stored.  Let’s suppose it’s an InfoCard from some Identity Provider, then the liability would then fall on that Identity Provider if/when a users account gets compromised.  Why would someone sign up for that?  In the case that we’re dealing with internally, Microsoft is the Identity Provider, and our lawyers don’t want to sign up for the risk – why would anyone else?

Thinking about this slightly differently – Our lawyers have the problem, because if someone hijacks my corporate user account, and goes into my 401k and wipes out my retirement savings – who is ultimately responsible?  If Microsoft did the authentication, Microsoft is, if the partner did it, they are, and if some 3rd party identity provider did the authentication – then THEY are responsible (would we even consider a 3rd party – umm…let’s hope not)

So let’s say we use an infocard.  And not only that, but we use a Managed infocard.  Ok, so now I’ve got a managed card on my machine – So when someone hacks my account, selects the highlighted infocard, and THEN wipes out my 401k… Now who’s responsible?

I can absolutely see where an InfoCard can help the end user – but I’m the IT Geek who’s trying to deploy the infrastructure.  How do I sell being an Identity Provider to my CIO?

Posted in ADFS, Digital Identity, Identity and Access, InfoCards | Leave a Comment »

 
Follow

Get every new post delivered to your Inbox.