Category Archives: Access Control

Recap of European Identity & Cloud Conference 2013

Posted on by

The 2013 edition of the European Identity & Cloud Conference just finished. As always KuppingerCole Analysts has created a great industry conference and I am glad I was part of it this year. To relive the conference you can search for the tag #EIC13 on Twitter.

KuppingerCole manages each time to get all the Identity thought leaders together which makes the conference so valuable. You know you’ll be participating in some of the best conversations on Identity and Cloud related topics when people like Dave Kearns, Doc Searls, Paul Madsen, Kim Cameron, Craig Burton … are present. It’s a clear sign that KuppingerCole has grown into the international source for Identity related topics if you know that some of these thought leaders are employed by KuppingerCole themselves.

Throughout the conference a few topics kept popping up making them the ‘hot topics’ of 2013. These topics represent what you should keep in mind when dealing with Identity in the coming years:

XACML and SAML are ‘too complicated’

It seems that after the announced death of XACML everyone felt liberated and dared to talk. Many people find XAMCL too complicated. Soon SAML joined the club of ‘too complicated’. The source of the complexity was identified as XML, SOAP and satellite standards like WS-Security.

There is a reason protocols like OAuth, which stays far away from XML and family, have so rapidly gained so much followers. REST and JSON have become ‘sine qua none’ for Internet standards.

There is an ongoing effort for a REST/JSON profile for XACML. It’s not finished, let alone adopted, so we will have to wait and see what it gives.

That reminds me of a quote from Craig Burton during the conference:

Once a developer is bitten by the bug of simplicity, it’s hard to stop him.

It sheds some light on the (huge) success of OAuth and other Web 2.0 API’s. It also looks like a developer cannot be easily bitten by the bug of complexity. Developers must see serious rewards before they are willing to jump into complexity.

OAuth 2.0 has become the de-facto standard

Everyone declared OAuth 2.0, and it’s cousin OpenID Connect, to be the de facto Internet standard for federated authentication.

Why? Because it’s simple, even a mediocre developer who hasn’t seen anything but bad PHP is capable of using it. Try to achieve that with SAML. Of course, that doesn’t mean it’s not without problems. OAuth uses Bearer tokens that are not well understood by everyone which leads to some often seen security issues in the use of OAuth. On the other hand, given the complexity of SAML, do we really think everyone would use it as it should be used, avoiding security issues? Yes, indeed …

API Economy

A lot of talk about the ‘API Economy’. There are literally thousands and thousands of publicly available APIs (named “Open APIs”) and magnitudes more of hidden APIs (named “Dark APIs”) on the web. It has become so big and pervasive that it has become an ecosystem of its own.

New products and cloud services are being created around this phenomena. It’s not just about exposing a REST/JSON interface to your date. You need a whole infrastructure: throttling services, authentication, authorization, perhaps even an app store.

It’s also clear that developers once more become an important group. There is nu use to an Open API if nobody can or is willing to use it. Companies that depend on the use of their Open API suddenly see a whole new type of customer: developers. Having a good Developer API Portal is a key success factor.

Context for AuthN and AuthZ

Manye keynote and presentations referred to the need for authn and authz to become ‘contextual’. It was not entirely sure what was meant with that, nobody could give a clear picture. No idea what kind of technology or new standards it will require. But it was all agreed this was what we should be going to 😉

Obviously, the more information we can take into account when performing authn or authz, the better the result will be. Authz decisions that take present and past into account and not just whatever is directly related to the request, can produce a much more precise answer. In theory that is …

The problem with this is that computers are notoriously bad at anything that is not rule based. Once you move up the chain and starting including the context, next the past (heuristics) and ending at principles, computers are giving up pretty fast.

Of course, nothing keeps you from defining more rules that take contextual factors into account. But I would hardly call that ‘contextual’ authz. That’s just plain RuBAC with more PIPs available. It only becomes interesting if the authz engine is smart in itself and can decide, without hard wiring the logic in rules, which elements of the context are relevant and which aren’t. But as I said, computers are absolutely not good at that. They’ll look at us in despair and beg for rules, rules they can easily execute, millions at a time if needed.

The last day there was a presentation on RiskBAC or Risk Based Access Control. This is situated in the same domain of contextual authz. It’s something that would solve a lot but I would be surprised to see it anytime soon.

Don’t forget, the first thing computers do with anything we throw at them, is turning it into numbers. Numbers they can add and compare. So risks will be turned into numbers using rules we gave to computers and we all know what happens if we, humans, forgot to include a rule.

Graph Stores for identities

People got all excited by Graph Stores for identity management. Spurred by the interest in NoSQL and Windows Azure Active Directory Graph, people saw it as a much better way to store identities.

I can only applaud the refocus on relations when dealing with identity. It’s what I have been saying for almost 10 years now: Identities are the manifestations of relationship between two parties. I had some interesting conversations with people at the conference about this and it gave me some new ideas. I plan to pour some of those into a couple of blog articles. Keep on eye on this site.

The graph stores themselves are a rather new topic for me so I can’t give more details or opinions. I suggest you hop over to that Windows Azure URL and give it a read. Don’t forget that ForgeRock  already had a REST/JSON API on top of their directory and IDM components.

Life Management Platforms

Finally there was an entire separate track on Life Management Platforms. It took me a while to understanding what it was all about. Once I found out it was related to the VRM project of Doc Searls, it became more clear.

Since this recap is almost getting longer than the actual conference, I’ll hand the stage to Martin Kuppinger and let him explain Life Management Platforms.

That was the 2013 edition of the European Identity & Cloud Conference for me. It was a great time and even though I haven’t even gotten home yet, I already intend to be there as well next year.

Found: Identity Provider Business Case, or not?

Posted on by

I had the pleasure to have been part of the Identity community in the “early days”. Right before OpenID came into existence and most people thought of Microsoft Passport as innovative. One very hot topic was the idea of an “Identity Provider”. An Identity Provider is a party on the Internet who would be happy to serve any claims about me to a any relying party, obviously with the user’s consent and control. Anyone remember the expression “user centric identity”?

There were some unsolved issues:

  • How would an Identity Provider make money to pay for the operational costs?
  • How would relying parties know which Identity Provider to trust?

Especially the second issue was hard. Some relying parties just want to be able to recognize recurring visitors and are happy with a couple of standard attributes. For them, identity has low value. Well known examples are the myriad of forum sites.

Other relying parties however want more, they want identities with verified attributes, an identity they can trust. For them, identities have value and untrusted identities come with a business risk. An extreme example would be a financial institution who would, for these reasons, typically never outsources the Identity Provider role.

A couple of days I came across an interesting article about Facebook offering their commenting system to other sites, including authentication through Facebook. What caught my eye was an argument showing that Facebook serves as an almost perfect Identity Provider in some sense:

This offers publishers a number of benefits. They get more links to their site from inside the net’s most popular website. A lot of people are “registered” to comment on their sites. And, they have a system designed to discourage vitriol because it’s easy for the site owner to ban a user and tough for a user to create a new identity.

Especially that last part is interesting: relying parties can put some trust in the provided identities simply because … people invest time and effort in their Facebook identity and generally would not throw this away just to post rubbish on some forum. In other words, relying parties will like Facebook identities. They trust one Identity Provider, Facebook, and they get hundreds of millions of fairly trustful Identities.

But what is in it for Facebook? A lot!

For Facebook, the benefit is also clear. Users now have even more incentive to be constantly logged into Facebook (those who are already logged into Facebook don’t have to do anything to comment on a website using its system). Additionally, even more of Facebook’s users’ net activities flow through its site, since by default comments — and replies to them — post to a Facebook user’s wall. That deepens users’ ties to Facebook, adds more content to Facebook, and gives people more reason to check their Facebook newsfeed for the increased information flow.

By allowing relying parties to use Facebook identities to realize a comment system on their site, Facebook actually generates value for themselves. A win-win it seems.

Facebook, with their Facebook Connect, wants to be the primary Identity Provider on the Internet:

It also builds on what’s becoming Facebook’s most important function: being the identity provider and validator for the wider net. The system opens the door for what’s likely inevitable: having news sites rely on Facebook to identify its users and eventually to serve ads to its readers based on their individual Facebook pages.

Both issues are gone: the Identity Provider (Facebook in this case) can have a very viable business model and the relying party has an Identity Provider they can trust, one that brings hundreds of millions of identities.

So, all well now in the world of Identity? I don’t think so. The relationship between Facebook and relying parties is not a balanced one. Relying parties are clearly at the mercy of Facebook:

… just as Facebook jealously holds onto the e-mail addresses of the people you are connected to on Facebook so you can’t re-establish your network on some other site.

Promising as it may seem, this type of unbalanced relationship should not satisfy us. So, for those still active in the field of Internet Identity, what do you think about this?

Some still don’t get it!

Posted on by

This post is about security, so if you are not into that, feel free to skip it.

Today I get a friendly email from the national railroad company of Belgium (NMBS) in which they announced a brand new site to order international train tickets. It also mentioned that instead of using my made up user name I could now use the email address I used while registering to log in.

That sounds great, another site that uses an email address to log in instead of something like “johnsmith342”.

Then they kind of messed up. For my convenience and to make sure I would be able to use their shiny new site to buy lots of international train tickets they included my password. Yes, you read that right, they mailed me my password. Without me asking for it.

They have no clue about processes and procedures for dealing with passwords. They are not helping the world in teaching people how to deal with authentication secrets, social engineer and phishing.

I can only hope the password is not stored clear text. Due to password policies it is often necessary to access the password in clear text, only storing a hash is not working any more. Common databases like Microsoft Active Directory, Novell eDirectory and probably many others use two way encryption to store passwords. They have many secure access layers between a public api and the encryption keys to access to the clear text version of the password.

Honestly, emailing me my own password without my consent doesn’t generate a lot of trust in how they deal with sensitive information. That includes my trust in how they store my password in their systems.

(EIC-2009) Claims is what we have, claims is wat it will be

Posted on by

[Blogged from the 2009 edition of the European Identity Conference]

Slowly I am getting the impression that Microsoft is going to use claims for everything even remotely related to identity. During discussions at EIC 2009 I understood that Microsoft is also positioning claims for authorization. This is not entirely new, in their Azure Cloud Services offering they positioned claims this way: for authorization.

I am not feeling a 100% comfortable with this. Without more and detailed information on how Microsoft will realize it, I can hardly judge their strategy but here are some of my worries:

  • Is the claims request/response protocol capable of supporting authorization? XACML obviously has a more rich model that allows for fine grained context descriptions and nuanced responses (e.g. obligations). With claims it’s more simple.
  • Using claims for authorization makes the solution attribute driven. That opens the door for a heavy dependency on roles: roles are easy to represent in a claim. As far as I know Microsoft doesn’t have a solution to manage roles. Perhaps they have something on the horizon?
  • Microsoft already indicated that roles as we use them today are incomplete. They are looking for a standard way to accompany roles with predicates. For instance “The user has the role ABC but only between 9AM and 5PM”. I can agree with the usefulnes and semantics of this roles-predicates marriage but I smell a box of pandora: so many ways to mess this up.
  • Claims are a powerful concept and we can thank Kim Cameron and Microsoft for defining and pushing this. But there is this saying in Flanders “if the only tool you have is a hammer, everything looks like a nail”. This is a real trap for Microsoft: using claims to solve every IAM problem. I see the first signs of claims semantics being stretched too far.
  • Lastly, informally I heard some ideas on how they will align Sharepoint with the claims world (specifically in terms of authorization). Policies would not evaluate to authorization responses but might evaluate to query-like structures that can be used by Sharepoint to select the resources you have access rights for. I am not sure if I understood this correctly so I am going to hold back on commenting.

It will be interesting to see how all this will be evolving in 2009 and 2010. I assume more on this during EIC 2010.

LDAP Referential Integrity

Posted on by

An old issue with LDAP servers has found the spot light again: referential integrity. This time it’s a call for attention made by James:

I also asked the question on How come there is no innovation in LDAP and was curious why no one is working towards standards that will allow for integration with XACML and SPML. I would be happy if OpenDS or OpenLDAP communitities figured out more basic things like incorporating referential integrity.

Pat pointed James to what he thinks is prove of support for referential integrity in LDAP (OpenDS, OpenLDAP and any Sun derivative):

For some reason, James has a bee in his bonnet over referential integrity and LDAP. I’m really not sure where he’s coming from here – both OpenDS and OpenLDAP offer referential integrity (OpenDS ref int doc, OpenLDAP ref int doc), and Sun Directory Server has offered it for years (Sun Directory Server ref int doc). Does this answer your question, James, or am I missing something?

I can’t answer for James of course, but if I had been asking that question … no Pat, it does not answer my question. Well, it kind of does, since it confirms that those LDAP incarnations have limited to no support for decent referential integrity. Let’s follow one of Pat’s links and see what it says (Sun Directory Server ref int doc):

When the referential integrity plug-in is enabled it performs integrity updates on specified attributes immediately after a delete, rename, or move operation. By default, the referential integrity plug-in is disabled.

Whenever you delete, rename, or move a user or group entry in the directory, the operation is logged to the referential integrity log file:

instance-path/logs/referint

After a specified time, known as the update interval, the server performs a search on all attributes for which referential integrity is enabled, and matches the entries resulting from that search with the DNs of deleted or modified entries present in the log file. If the log file shows that the entry was deleted, the corresponding attribute is deleted. If the log file shows that the entry was changed, the corresponding attribute value is modified accordingly.

So it seems that Sun Directory Service let’s you delete a user but it promises to make sure that it will do it’s very best to delete any references to this user within a “update interval”. It does not mention what a read after the deletion but before the plug-in kicks in will see. Will it still see the user as a member in a group although the user is deleted? I am pretty sure it does. This is of course, at least for me, enough prove that this functionality does not offer referential integrity. At best it offers some kind of deferred cascading deletes (or updates) with no semantics for reads done during the time interval between the original operation and this cascaded deletes and updates.

Does this mean an LDAP server is something to avoid in any production environment? Absolutely not! In fact, I am not even sure if an LDAP server should offer “real” referential integrity at all. If you need that kind of guarantees, you are not far from full transaction support either, so why not upgrade to a relational database? Just my 2 cents of course.

To Sun (and any other LDAP implementator): what would the impact be on read/write performance in LDAP if they would implement full referential integrity?

DropBox + PasswordSafe = Good ??

Posted on by

When I read Joel Spolsky’s post about DropBox combined with PasswordSafe I kind of fell from my chair. Apparently he was looking for a way to store his passwords in a safe way and be able to access them on any computer he uses. This is what he proposes:

  1. Install DropBox on all your computers. DropBox is a simple tool to synchronize a local folder to an Internet site. It will synchronize the contents of the folders so you’ll have your data, latest version, available on all your computers. Note that DropBox is secured by a username and password send over the Internet (using SSL of course, at least I hope it is).
  2. Install PasswordSafe on all your computers. This is an application that creates a database to store and generate passwords. It uses a password to encrypt the database. The usual algorithm is deployed: the password is used as input for a derived key function which is then used to encrypt the database. PasswordSafe can generate long and random passwords for you and helps you enter them into login forms.
  3. Store the PasswordSafe database in the DropBox folder.
  4. …
  5. Password Nirvana!

Joel even suggests to go all the way and change your bank account password to something really hard (like 16 random characters) and store it in PasswordSafe.

Joel seems to think that this is really all safe since he is using long and hard passwords on websites (those 16 random PasswordSafe passwords) and the “derived key function” used to encrypt his PasswordSafe database. Well Joel … I don’t think so. This is a clear case of “security dependencies” or “weakest link” …

Let’s see what I need to do to get at Joel’s really long and hard to guess 16 character password for his bank account.

  1. I need to hack into his PasswordSafe database. In order to do that, I first need access to it …
  2. I need to hack into his DropBox account. Doing that requires the usual hacking of a username and password on a Internet site. With the DNS flaws and various Phishing techniques that is not even that hard these days. Not to mention that this is worth the effort, after all it will give me access to his bank account!
  3. Now that I have his PasswordSafe database, I need to decrypt it. I don’t care a single moment about the strength of the encryption algoritm nor do I care about the valueness of the derived key function. The only thing I need to know is his password. Since I have the database offline and there is no mechanism whatsoever to discourage a brute force guessing attack, this is purely a matter of time. The attack is even undetectable since it happens on my local infrastructure.

Whatever cool encryption and synchronisation mechanism this setup uses, eventually the entire security depends on just a username and password. Since he wanted to protect a password login in the first place (his bank account) I wonder what he actually achieved in terms of increased security.

My first idea would be to say that he has replaced password based security with … password based security. The only that has changed are some extra, but minor, hurdles to hack it all. But I would even go further. He ends up less secure since cracking his PasswordSafe opens up all his accounts for me, not just his bank account, and the overall attack is less detectable then if I would hack his bank account directly.

Addendum … this article discusses the same topic but using different examples:

To use an analogy (certain to spike my readership, even if only till the US political process spits out some other triviality to focus on) you can put lipstick on a pig, but all you’ll end up with is a cosmetically enhanced porker.

Similarly, you can plaster on the lipstick of strong authentication like Tammy Faye but, if you are smearing it onto a pig of an identity proofing procesess, you’ll still be eating the bacon of low assurance …

Ben Laurie’s Capabilities

Posted on by

The blog of Ben Laurie is on my blog roll since ages (well, Internet ages). He often has great and refreshing views on topics like identity, privacy or security. On top of that, the quality of the post has always been excellent. If you don’t have his feed in your reader, now would be a good time to include it.

One of the recent posts was about a paper he wrote on capability based security systems. I knew from university that depending on how you read a matrix mapping users, resources and access rights, it would be an access control list or a capability list. Therefore it looks at first sight as if access control lists and capability lists are semantically the same. You either store the rights on the resource itself and it becomes an access control list (most common example is a filesystem). You can store all the rights associated with a particular user and it becomes a capability list. Perhaps this was a simplification done in the textbook we had but it certainly has a degree of logic to it. As Ben explains there is a subtle difference between the two concepts and although they have a lot in common, they are not entirely identical in terms of protecting access to resources.

A good example of the difference between a system based on access control lists or a system based on capabilities is given by Ben in the paper. In a typical application, when a user needs to safe a file, the user is presented with a Select File dialog. Based on this selection the application will ask the operating system to open the file. Based on the access control list on that file, the operation will be allowed or not. In a capability based system, the Select File dialog could be a trusted component presented by the operating system, similar to the card selector of Infocards in Windows. The selection of a file would result in a capability to open that particular file. The application can then use the capability to access the file. In an access control list based system, the file selected by the user is not necessarily the file being accessed by the application. If the applications intentions are not good, it might decide to open a different file. In the capability based system, this would not be possible.

Ben also states that there is room for both systems: access control lists and capability based systems. Depending on the environment and the specific requirements, one system will be better suited then the other. In particular Ben sees capability based systems as very promising in the context of securing various (semi) executable content in web pages. Examples include HTML and scripted content from foreign sources in a web page. A technique more and more used in social networking sites or personal portals as iGoogle.

Although I agree with Ben’s reasoning (who am I to question his experience and knowledge) there are some points in the whitepaper that I don’t fully agree with. In some of the later examples of the whitepaper, Ben starts to play with capabilities. By wrapping them in security containers (for instance signing) they can be passed over untrusted third parties. Capabilities can also be wrapped inside other capabilities to accomplish further control over the right granted.

In most of the paper, the definition of a capability can be fairly strict: it’s represents a capability, something the bearer can do with a resources (or a set of resources, whatever the capability points at). In the examples later in the paper, this definition does not hold anymore and suddenly widens to mean a lot of things. In section 6.3 (“Proving User Choice”) of the white paper a trusted component needs to pass a user action to a second trusted component. It does however use an untrusted intermediate for this. In order to prevent the untrusted intermediate to play with this, the performed user action is represented as a capability. It depends on the definition of a capability of course, but I have a hard time thinking of “the user clicked on the second image” as being a capability. This is more like a claim issued by a trusted component (the trusted renderer in the example). To me a claim is not a capability.

It is probably a matter of defining “claim” and “capability” of course. Perhaps Ben can shed some light on this?

Single Account without OpenID or Carspace!

Posted on by

In the country I live, Belgium, the various utility providers have discovered the Internet as a place to interact with their customers. Over the last two years I received letters from all of my utility providers (electricity, gas, internet, telecommunication …) that I now can manage my account on their website.

Great! 24/7 I can login to their site and check my current balance, buy more features or do whatever that needs to be done.

Today however, I am running away from them. Each and every one of those sites requires me to register, including creating a new account with user name and password. Not to mention how difficult it often was to correlate my existing products with that new online account.

Almost every time I have to login to those sites, I forgot the user name or password I picked at registration. I do try to keep a single user name for that kind of accounts but that is not always possible due to conflicting rules or my default user name already taken.

Today I realized that I am not even bothering anymore to remember the user names or passwords. Somehow I found a way to use my Google Account on all of them. Instead of supplying my user name and password to that site, I use the following procedure:

  1. Surf to the site
  2. Immediately pick the “Forgot user name or password” link, I don’t even bother trying to log in
  3. Enter my Google email address somewhere (all those sites offer to mail you your existing or new credentials, either based on email address or based on user name)
  4. Wait for the mail to arrive in Google
  5. Open it, click on the link inside
  6. Create a one time password and log in with it
  7. Use the site

The only account I have to remember is my Google Account. Now I just wait for someone to write a Firefox add on that automates most of the above.

So if the following companies would be so kind to read up on OpenID so I don’t have to act like a fool with the above procedure: Electrabel, Telenet, Belgacom, Nuon, Proximus, Luminus … and probably others I forgot.

Plaxo and OpenID (Problem 2)

Posted on by

Plaxo upgraded their OpenID libraries a while ago and this gave some issues. Those are fixed now, thank you Plaxo.

Now that I am blogging about Plaxo’s OpenID support, let me start the second problem I have. Each time I receive an invitation to connect to someone I know at Plaxo, Plaxo shows a different URL to identify itself at my OpenID provider (MyOpenID). We are talking long and complex URL’s containing numerous GET parameters.

The result is that the list of known URL’s at my OpenID provider is getting longer and longer every day and Plaxo is already taking up over 60% of that list. The screenshot below shows a subset of this list:

Plaxo OpenID URLs

I don’t know if this is by (OpenID) design or not. What I do know is that when I have to accept a site, identified by a long and complex url, requesting my information, I don’t really know if I should accept or not. This makes phishing a little easier to do, just throw a complex URL at the user, he can’t validate it anyway. To make matters worse, MyOpenID layout does not even show the entire URL to me, it clips of in the initial screen where I can “Allow Always”, “Allow Once” or “Deny” and in the list of sites I took action on.