29.06.2012 by Martin Kuppinger
This week Jackson Shaw commented in his blog on an article written by John Fontana. The discussion is about the future of passwords and how federation and structures with IdPs (Identity Providers) will help us to avoid them. Both have somewhat different opinions. However, in both posts there is the idea of having an IdP, using federation, and getting rid of passwords.
My perspective is a little different and I’d like to add two important points (even while I think that Jackson is right with his skepticism regarding a quick replacement of passwords and with highlighting that password management solutions will be required by many organizations):
1) There is the need to authenticate to the IdP
2) We won’t rely on a single IdP in future
For the first point you might argue that you can use stronger authentication mechanisms relying on more than one factor (i.e. more than knowledge, more than what you know) when relying on a central IdP or a very few trusted identity providers whose business it is to secure everything. But:
- We’ve learned that nothing is fully secure – think about the RSA incident last year and many other incidents.
- We’ve learned that companies earning money for providing a high level of security do not necessarily care much about their own security – think about the DigiNotar scandal.
- We know that it is pretty complex and costly rolling out hardware-based two- or more-factor authentication – and pure software-based approaches have a tendency to be more limited regarding security. Approaches which require specialized hardware are unlikely to succeed, so until NFC (near field communication, with its own security issues) or security technology built into chipsets becomes standard, we will struggle with this.
- We also know that user acceptance is key to success – and many of the strong authentication approaches just fail here, like virtually all types of biometrics.
So passwords might still be the approach used by the central IdPs, leaving us in the “sad world of passwords” mentioned in these posts.
Even if we can solve these issues, there is the second one. The future will not see us relying on a single IdP. The future is about having multiple IdPs, even different IdPs for a single transaction and for different claims within one authorization request. I’ve touched on this topic repeatedly in my recent posts.
So many approaches like NSTIC are or might be limited in that they are country specific. NSTIC is driven by a US agency. It shall be usable globally. But will it be accepted globally? Or will others decide for somewhat different approaches? LinkedIn and all the others mentioned by John Fontana can’t rely on anything which is focused on one country. They will have to support IdPs from all over the world, with different implementations and different levels of identity assurance. And that is true for everyone relying on the concept of IdPs and related SPs (Service Providers) or relying parties. Trust frameworks will be dealing with the complexity of having many IdPs (By the way: the Personal Data Stores John Fontana points to won’t help – Life Management Platforms, as described here and in the related report at least provide some support but not directly for authentication). Clearly nothing of this is about a world without passwords. That might happen when you rely for some interactions and transactions only on IdPs, which assure the authentication based on n-factor-authentication with n>1 and not being pure knowledge. But it isn’t essential for any of these concepts – and as I stated: The fact that we will use more IdPs, moving away from an approach with “the central IdP everything relies on”, we will see a mix of authentication mechanisms.
You could “chain” such IdPs and rely on one strong, primary authentication. But then you are back at defining who that could be, setting up the entire “backend part” (between IdPs) of the Trust Framework, and by having one who is trusted by all AND accepted by the user.
So my view is that there is little hope for a world without passwords within a foreseeable period of time. We might reduce the number of passwords; we might use stronger technologies in many situations. But relying only on federation and Trust Frameworks and so on is not about getting rid of passwords.
22.06.2012 by Martin Kuppinger
Some days ago I had a very interesting briefing with IBM on their CastIron products. I had been in touch with CastIron way before they became part of IBM, because CastIron was one of the most interesting start-ups around “Cloud Integration”, i.e. the ability to integrate different cloud services and on-premise applications using the exposed APIs.
Since then a lot has happened. The number of available APIs exploded, as my colleague Craig Burton has described in his report on the Open API Economy. More and more vendors are entering the space and are picking up the term Open API Economy. The concept is increasingly understood, enabling new models and real flexibility, going well beyond the big, fat, monolithic SaaS apps we, for the most part, still find today.
When talking with IBM CastIron, they explained their approach of integrating different pieces into a more complete solution. These pieces are
- IBM WebSphere CastIron
- IBM Worklight
- IBM Web API Services
The latter is software – the full name appears to be “IBM Cast Iron Live Web API Services” – which allows creating, sharing, and managing APIs. So the entire portfolio consists of technology for orchestration (WebSphere CastIron), for integration with mobile devices (Worklight) and for the core features of creating, sharing and managing the APIs (Web API Services). This combination allows supporting different use cases for the Open API Economy, from both the “API consumer” side – i.e. the organizations relying on APIs exposed by others – as well as on the “API provider” side – i.e. the ones exposing APIs. Over time, most organizations will be part of both sides, exposing and consuming APIs.
The IBM Web API Services include security features which allow you on the one hand to enable participation of external developers in building applications based on the APIs and on the other to also control which APIs are exposed to whom. Some APIs might need to remain internal, some might be only available to restricted groups of partners and other users, and some might become public. I also like the management features and dashboards, showing, for example, the top API calls, developers, and applications.
The investment IBM is making in that market is another indicator that the Open API Economy will greatly influence the future of IT. The Open API Economy will massively affect the way we deal with data, allowing us to move from Big Data to Smart Data; it enables the integration of different Cloud environments amongst themselves as well as with on-premise IT; it supports the concepts we’ve described in our KuppingerCole IT paradigm, our guideline for how to embrace and extend your existing IT and get a real grip on the cloud; and it allows us to move from building and maintaining apps and web-sites towards just exposing the APIs, allowing others to build the apps they really need. The latter is worth a little more explanation.
Consider the situation of public transportation today: each provider is struggling with building its web sites and apps for the customer. Supporting new devices and keeping things up-to-date costs a lot of money. By exposing APIs which provide information about the current status, a developer will be able to create an app which indicates when you have to leave your home to catch the next bus or train, based on the information provided by the public transportation service. This could run on your mobile phone, order the ticket automatically, alert you, and add whatever other services you might want to have. It would rely on exposed APIs and could integrate with other exposed APIs – the app could also say: Better take your car, because the busses are delayed but the streets are empty.
I really like to see companies like IBM and others like 3scale, Layer 7 Technologies picking up these concepts. IBM has right now, with the addition of the Web API Services, an offering which covers many different aspects of the Open API Economy and really picks up the concepts of this fundamental change we are observing.
18.06.2012 by Martin Kuppinger
I first thought about ignoring this topic for my blog. However, there have been so many press releases, blogs, and other comments on it which have been just wrong or absurd that I finally decided on posting a little about it.
First of all, the LinkedIn Password Disaster reinforces the old rule that you shouldn’t reuse passwords (at least not too much).
Second, it is another proof of the fact that the security skills of developers are on average far too low. There are not enough developers with strong security skills, but many developers with a lack of good skills in security which are developing security features anyway. LinkedIn obviously had a lack of security experts in its architecture, development, and operational teams. Security has to be part of application development from the very beginning. It is not something which can be added afterwards.
However, even IT education largely fails in that area. Instead of having IT security as one of the most important parts of any IT education, it is still seen as something for some experts. That’s wrong. IT Security has to be a core subject of any IT education. And it should be a mandatory examination subject for everyone studying informatics.
Unfortunately, that helps only in the mid-term or long-term. Just last week I had the discussion about whether it makes sense to acquire a company of experienced app developers without security skills to develop security apps. Every expert involved agreed that this doesn’t make sense. It is pretty hard to impart security skills while it’s comparatively easy to impart app development skills. So the battle for the relatively few security experts out there will continue.
Another important aspect is that certification will hopefully gain momentum. That doesn’t always help. There were cases some years ago where sites that had been security certified by the German TÜV were hacked. Nevertheless, such beginner’s mistakes in security like the ones at LinkedIn could be avoided by certifications.
Besides these points, what really caught my attention and led to this post were the press releases of vendors of OTP technologies (one time passwords) and other security technologies which promised a better world when using their technologies. However even while passwords are a weak mechanism, when looked at realistically, there is no short-term replacement. Yes, federation (in a somewhat different form from today’s approaches) will change a lot over time. But I don’t see that things like OTP or others will really work for the use cases of sites like LinkedIn. So I think we will have to live with passwords. It’s up to companies like LinkedIn to avoid the biggest mistakes on their side. And it’s up to us to avoid the biggest mistakes on our side.
17.06.2012 by Martin Kuppinger
Over the course of the last few days, there have been many posts being published in different blogs, including the ones of Craig Burton, Nishant Kaushik of Identropy, KuppingerCole’s Dave Kearns and for sure Kim Cameron and John Shewchuk.
I won’t dive into the discussion taking place between Craig, Nishant, Kim and others but clearly have to say that I’m fully with Craig on that it is about “Freedom of choice” and that this is fundamentally different from the “Freedom to choose your captor”.
My main points later down will focus on the blog of John. However, when looking at the initial post of Kim, there is also one important aspect I want to stress. Besides the fact that we will use more identity services and that they have to provide a lot of features, there is another important trend which I observe. We will in the future rely on more than one identity service. The fundamental change is that the relation of authentication and authorization will change from a 1:n relationship to a m:n relationship. What does this mean in reality?
Today we tend to have relatively static access management, where a user authenticates, obtains a ticket or something like that and then this ticket from one identity provider is used for several authorizations within a session. This will change. When you look at the idea of claims, they potentially can be issued by different identity providers. They are used in dynamic authorization decisions. You might even have different claims from different providers per decision. Trust might differ depending on the importance of the claim and its provider. It’s sort of a convergence of authentication and authorization. And in that world where you receive attributes (or claims) for authorization decisions from many providers, the role of identity providers will change. Microsoft’s WAAD approach its the planned interfaces definitely helps in moving towards such a concept.
But let’s now look at John’s post and some things I’ve learned since then. He focuses pretty much on WAAD as something that is mainly made for Office 365 and Azure, so it is the classical Microsoft-focused environment. However that raises the question: “Only for these environments?”
That, from my perspective, is one of the big questions: How can you make that work for everything in a controlled, secure way? I assume this will be covered more in depth in the next part of John’s blog. And from what I know today, besides a set of RESTful APIs there will be other interfaces, including OpenID connect, SAML and so on. However there won’t be an LDAP interface at the beginning, even while you could potentially build that by wrapping the RESTful APIs. Not supporting LDAP directly at the beginning definitely is somewhat surprising, but it stands also for a change towards what we call the Open API Economy (have a look at Craig’s blog and the KuppingerCole report on that topic).
Another interesting question which came to my mind was: What about structuring Active Directory? The biggest problem with Active Directory from my perspective never has been running the directory itself but dealing with two issues
- Structures like domains and forests (and even more: restructuring)
- Security, as well inside AD as by defining different types of groups in an appropriate, manageable way
When reading the post it sounds (implicit, not explicitly) as if Azure AD is sort of a flat “name space”, which isn’t sufficient for every organization. How about dealing with multi tenants owned by a large organization? How to structure it internally? How to get better managing groups and so on? Claims provide some answers (in fact the topic of Dynamic Authorization Management does, where claims are one element) but there needs to be much more information about that. I don’t necessarily expect that in the first post of a series, but it needs to be addressed. So I’m interested in learning more about these points. WAAD looks quite interesting, but there are many open questions