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
16.11.2011 by Martin Kuppinger
Cloud Computing is just another delivery model for IT services. However, due to the specifics of cloud services like multi-tenancy and many others, requirements sometimes are even higher than for on-premise services. One of these requirements in well-architected IT environments and for well-architected applications is the ability to externalize security. That includes relying on external directories for administering and authenticating users, e.g. on Identity Providers. It might include the capability of “cloud provisioning”, e.g. receiving changes of users – even while I clearly favor federation as loosely coupled approach over provisioning. It should include the support for external logs, event monitoring, and so on – unfortunately that appears to be a topic where noone is really working on.
And it should include the capability of managing authorizations in cloud services based on centrally (on-premise or using a cloud service – but centrally and not per cloud service!) managed policies. There is limited value in federating users and than doing all the administration work per cloud service using the cloud service’s proprietary management GUIs or APIs. However, authorization is where the problem really starts.
There is a standard for distributed, dynamic authorization management out there: XACML, the eXtensible Access Control Markup Language. It allows to describe the rules. It allows to work with different repositories for identity information (PIPs, Policy Information Points) and other information required for authorizations, it provides interfaces to custom and standard applications, and so on. However, I haven’t seen XACML in the cloud until now. Unfortunately, I also haven’t seen any real alternative to XACML.
Some might claim that SAML might do that job. There is the SAML Authorization Decision Query as part of the SAML 2.0 standard. But that leads pretty quickly to SAML/XACML interoperability and things like the SAML 2.0 profile of XACML. In fact, if it is about having a consistent set of policies expressed in a common standard, XACML is what we need. We need to define and manage these policies consistently per organization, not per service. Services should request authorization decisions – at least in an ideal world. However, when looking at the cloud, there comes another aspect into play: Performance. Performance is a general issue when externalizing authorization decisions. For cloud services which have to ask many different authorization “engines”, it is an even bigger issue. And there is the issue of latency, which is a factor in cloud environments due to the geographical distances you might find there.
Thus, while XACML is fine for defining policies, the interesting question is: Should cloud services ask external authorization engines per authorization decision? Or is it the better way to update the relevant XACML policies at the cloud service and do authorization decisions there? However, then we will still need a way for efficiently accessing the PIPs for other attributes required to perform the authorization decision.
I don’t have the full answer. However I’m convinced that XACML is a key element for authorization in the cloud, given that it is the standard for externalizing authorization decisions. But it might need some enhancements to optimally work for cloud security as well. It definitely will need improved security architectures for cloud services themselves to externalize authorization decisions and to rely on centrally managed policies. And it definitely needs some thinking about the overall security architecture for cloud services. So I’m looking forward to comments on this post – maybe I’ve missed something and everything is there; maybe this initiates some enhancements to standards. I don’t know but I’m really curious.
23.04.2011 by Martin Kuppinger
There is a new initiative driven by Google, salesforce.com, and Ping Identity called SCIM (Simple Cloud Identity Management). It claims to overcome the shortcomings of SPML (Simple Provisioning Markup Language), a standard being around for some 10 years. SPML has the target of being a standard for provisioning information between systems. It is supported by most provisioning and access governance tools, but only few target systems. SAP probably is the most important supporter.
Google, salesforce.com, and others in the cloud don’t support SPML. Thus, provisioning to these systems requires using proprietary APIs, if available at all – Google and salesforce.com provide such APIs, but not every cloud provider does. To overcome this, work on SCIM has started.
The first question however is: Why not use SPML? The main reason might be that SPML is XML-based, not focusing on REST which appears to be the somewhat more efficient (and especially, more accepted) way to implement standards for the cloud. Another might be that SPML is moving forward very slowly, if moving at all. There are many defencencies in SPML, no doubt about that. These start with the limited support by non-IAM-vendors. There are technical limitations as well, including performance issues in large scale deployments and limitations regarding what could be provisioned via SPML.
Nevertheless, I’d like to ask two questions:
- Wouldn’t it be better to join forces of SPML and SCIM to build a SPML version 3.0 which supports REST as well?
- If working on a new or improved standard, wouldn’t it make sense to address all relevant use cases? SPML doesn’t today and SCIM is not likely to do, when looking at the information provided today.
The first aspect seems to be more sort of a political issue between different vendors. However, having two standards doesn’t help anyone at the end of the day.
That’s even more true if both standards are too lightweight and don’t cover all the companies need today. When looking at the little piece of SCIM specification published it looks like SCIM will only touch the surface of what is required. The use cases are focused on providing user information to cloud services. However, the topic isn’t identity management, it is identity and access management. The access or entitlement part is the big thing to solve. Dealing with different APIs of different cloud providers for identities is an issue, but it isn’t the biggest one – several vendors (federation, classical on-premise provisioning, cloud provisioning) have addressed this at least for the leading cloud providers.
But what about controlling who is allowed to do what in these services? How to manage entitlements, e.g. group membership, authorization rules, and other things? XACML is a standard which supports this, but again there is little to no support by cloud providers for XACML – like with SPML. Thus, when starting to define a new standard, it shouldn’t be a too simple one, which SCIM appears to be at that point of time. It has one which covers all relevant use cases of identity and access management. There is only limited value in providing user information to a cloud service but still having to enter the proprietary web administration interface (or using some proprietary APIs) to control access for that user, to define groups, roles, policies, and so on.
My conclusion: There should be open standards for identity and access management in the cloud. Building on proprietary services is about repeating errors made before. But a new standard shouldn’t be too limited from the beginning. That, by the way, is one of the reasons I see behind the very limited success of SPML: It was too limited. I remember a conversation with one of the leading people involved in SPML years back from now where I suggested looking at use cases like supporting client lifecycle management solutions, e.g. tools supporting (amongst other features) software deployments. There are vendors today in the client lifecycle management market building custom integrations to HR or provisioning tools today, but not based on SPML – because they have never heard about SPML and because SPML never looked at this use case.
There might be a good reason for an effort like SCIM. But just being a REST-based standard but not really thinking beyond what SPML supported won’t solve the real world problems. Thus I strongly recommend to rethink SCIM and to look at significantly extended use cases.
If someone likes to discuss this with me in person, best is to meet at at EIC in Munich, May 10th to 13th.
06.08.2010 by Martin Kuppinger
Amongst the different vendors I’ve spoken recently, JanRain is definitely one of the most interesting ones – and will most likely make it into the list of next year’s Hidden Gem vendors. JanRain has had some popularity as one of the initiators of OpenID and with their OpenID libraries and other related services. However, they have made an interesting move during the last years and now provide what they call a “user management platform for the open web”. In fact, they provide products for web sites and social networks to enhance the user experience around registration and the services which deal with user data.
Amongst these products are solutions which enable web site developers to quickly integrate registration features which rely on social networks such as Facebook – use your Facebook account to register… There are several other services on top of this. But there are as well capabilities for stepping up in the authentication depending on the types of interactions and transactions someone is doing.
JanRain has managed to find an appealing and obviously successful business model around identity services. They are not focused on any particular type of authentication like Information Cards or OpenID but provide the frameworks to deal with all these different approaches. And that is exactly what most organizations need today when building their online presence: Flexibility in dealing with different online identities and an user-centric approach which allows users to quickly and easily register. JanRain definitely is worth a look for any web developer and especially for all the people responsible for online marketing.
30.07.2009 by Martin Kuppinger
These days I have learned that Fischer International Identity has trademarked to pretty generic terms:
- Identity as a Service (TM)
- IaaS (TM)
I wondered (and still wonder) about that. Fischer declared that they have invented that type of business (“a services-based architecture built from the ground-up for the express purpose of cost-effectively delivering identity management capabilities via the Software as a Service (SaaS) model”), built on a SOA architecture, supporting multi-tenancy, being able to work across firewalls. Honestly: Yes, they are an innovator in that space.
Unfortunately, that isn’t the only technology to which the terms mentioned above are applied. There are many different identity services. External identity providers for OpenID, strong authentication services, SSO for the cloud,… – to all these services the terms IaaS (TM) and Identity as a Service (TM) are frequently applied. And if you look at Application Security Infrastructures, then it is as well about providing identity services.
Thus, I agree with Fischer that they are sort of a pioneer in providing “provisioning as a service” (which would be PaaS) but I don’t agree with their view on that they have invented they entire market space for which these terms are used today. Anyhow, it is a little like Daimler having trademarks on “car”, “Automobil”, and other related terms, isn’t it!?
On the other side: Maybe I shouldn’t bash on Fischer for trademarking (why not try to get them?), but the ones on the governmental side which have agreed to trademark these very common terms. What will be next? SaaS (TM)? Cloud Computing (TM)? I really can’t understand that such common terms are trademarked (and I will use some related but somewhat different terms in the future). However, anyone who uses these terms has to attribute ownership of the mark to Fischer International Identity, like they have stated. Let’s look how they deal with the trademarks in practice. And be careful when using these terms.
To comply with the trademarking stuff: Identity as a Service (TM) and IaaS (TM) are trademarks owned by Fischer Internation Identity.
30.06.2009 by Martin Kuppinger
I’ve seen many approaches for strong authentication – most of them are either too expensive, too complicated, or they aren’t really appealing. The latter is true for approaches like “passfaces” have to pick one or some known faces from different pictures. Many approaches are complicated to deliver. And many of the token-based approaches are complex from a logistics perspective and are expensive. However, many of these approaches and especially combinations of for example hardware tokens and soft-tokens will work for many use cases.
But there are other approaches which are interesting as well. One which looks pretty interesting is GrIDsure, provided by an UK vendor and implemented by several OEMs right now. The idea is to provide a grid of numbers and to define a pattern within this grid per user. One user might decide on picking the numbers in the corners, clockwise. The next one might pick numbers from the second line from the right to the left. Even a relatively small grid allows for many different combinations. And due to the fact that the numbers within the grid change every time, there is a very high number of changing PINs which then can be entered. The concept is easy to understand, doesn’t require additional hardware and works with any type of device with a display.
Despite being really reluctant when a new vendor appears and likes to tell me that he has found the solution for strong authentication, the conversation with GrIDsure was definitely interesting. At least interesting enough to cover it in my blog and to do further research on that solution.
18.03.2009 by Martin Kuppinger
Authorization management is becoming increasingly popular. But there are, in fact, two very different approaches:
- Static authorization management, where changes are provisioned to the target systems.
- Dynamic authorization management, where authorization decisions are externalized to authorization engines at runtime.
The latter require changes to the applications, but they lead to the externalization of authentication and authorization (and hopefully as well auditing) from applications. Everything can be easily managed from outside of the applications.
Whilst static authorization management is provided by provisioning systems (at the more technical level) and by several GRC vendors (from a business control perspective), vendors of solutions for dynamic authorization management are still relatively rare and, besides this, in most cases relatively small. Besides Oracle with their Entitlements Server and, to some degree, CA with their Embedded Entitlements Manager, vendors include companies like Bitkoo or Engiweb, to name some of the two which are particularly interesting. And, for sure, Microsoft’s approach for claims leads in that direction – but at least in the current approach, authorization decisions aren’t externalized yet.
From my perspective, externalizing these decisions from applications definitely makes sense. Policies can be managed centrally, changes are effective immediately, and application developers don’t have to think much about security. They just rely on external decisions. In fact, things are moved from coding not only to deployment, but to runtime.
There are three challenges:
- The authorization engines have to be fast
- They have to be integratable with other IAM/GRC tools for a consistent management
- The applications have to be adopted to a specific solution
The first part is just an architecture and engineering task which has been solved by several vendors. The second requires, from my perspective, standards for the description and exchange of policies which are still widely missing. The third part could also be addressed by standards. That would give customers the choice between different authorization engines. As long as these standards are missing, customers should, with respect to the last bullet point, focus on implementations which require few changes in applications to minimize the risks of vendor lock-in. On the other hand, the advantages of such approaches are significant – and vendors like Bitkoo and Engiweb are succesful because of that fact.
From my perspective, companies should start looking at these approaches today and really start externalizing security out of the code.
By the way: We’ve given our European Identity Award in the category best innovation in 2008 to some of the vendors mentioned above. Attend European Identity Conference 2009 and learn, amongst many other things, who will be awarded as innovator this year.
The need for standards
28.01.2009 by Martin Kuppinger
I blogged several times about IaaS (Identity as a Service), last time only some two weeks ago. We will observe a strong increase in that field, the stronger the more people understand that IaaS is mandatory for the cloud. In our upcoming Market Report Cloud Computing 2009 (available starting tomorrow at http://www.kuppingercole.com/reports) we provide, first time ever, a stringent and valid structurization of the cloud market with all its different segments.
IaaS is part of this market, but it is as well a prerequisite for most other aspects of cloud computing. The more services you use in the cloud, the more you need IaaS and GRCaaS (GRC as a Service, just to create a new horrible acronym). How will you become ever compliant if you can’t manage your identities and their access rights consistently in the cloud? That goes well beyond authentication. We will need approaches for a consistent policy management across different cloud services, which again will require new standards, going beyond what federation standards like SAML, authorization standards like XACML and other standards like the IGF (Identity Governance Framework) provide today.
The biggest threat in cloud computing is manageability. And within that field, the biggest threat by far is managing the identities, their authentication, the authorization and all the auditing stuff, to meet the business policies and rules defined within more advanced GRC approaches. Thus, within a cloud strategy the IAM strategy is a vital part, and a prerequisite for every successful move to the cloud. That is true as well when using only a few cloud services (or even only consuming some external web services in SOA applications) as for approaches where everything including IAM and GRC is moved into the cloud.
We strongly recommend to evaluate today’s options for IaaS and their relationship to cloud strategies. By the way: European Identity Conference 2009 will be a great place to learn and discuss about this.
21.01.2009 by Martin Kuppinger
Some days ago, I had a very interesting discussion with John de Santis and some of his colleagues from TriCipher, one of the vendors which provide IaaS (Identity as a Service) solutions, in that case particularly with their MyOneLogin service. That discussion is one in a row of others I had with several of the other vendors in the IaaS space like Multifactor Authentication, Arcot Systems, or Ping Identity, to mention just a few.
On the other hand, my colleague Jörg Resch (currently very active in organizing the European Identity Conference 2009, where we will have, amongst many other topics around thought leadership and best practice for IAM and GRC, definitely much content about IaaS) some weeks ago asked me about my opinion about approaches like Facebook Connect and related standards (Google Friend Connect, Myspace Data Availability) and, as a result, my overall opinion about IaaS. First of all, the positive things with all these initiatives is that they address the lock-in issues in todays social networks, which I’ve discussed more than a year ago in this blog (by the way a discussion we’ve started at our European Identity Conference 2007).
So where is the link between these two discussions? It is all about the way we can and should deal with identities in the future. In business as well as privately. First of all, identity is core to any of these initiatives like cloud computing and SaaS or Enterprise 2.0 or Web 2.0 – even while many people haven’t understood the impact of identity yet. How will you ever fulfill compliance requirements in an IT infrastructure which consists of multiple SaaS services provided by different companies as well as some still existing internal IT services? How is allowed to do what in that environment? Just think about SoD controls across multiple SaaS services… How do we control the way our employees act in the Internet, still representing our company? What about consistency and reliability there? How about the integration of Web 2.0 services into the enterprise, for corporate use – that what sometimes is called Enterprise 2.0 (I use this term here even while most of the 2.0-terms are just ridiculous)?
It is interesting to observe that there are some initiatives and products trying to address at least some of the problems. Vendors start providing strong authentication as a service, sometimes focused on authenticating to SaaS. Social networks start to open up, even while there is a lack of standards. Information cards might become virtual corporate business cards.
Thus, we have some standards (like OpenID, Information Cards and the underlying federation standards, XACML,…), some IaaS services (mainly for authentication and federation and some provisioning), and some proprietary approaches for exchanging information from social networks. Many areas like policy management and auditing aren’t covered yet. And in the area of social networks, there should be one standard, which might make use of Information Cards instead of some vendor implementations. From my perspective, we are still at the very beginning of the IaaS market. We will need to create more standards and implement more use cases. There is a lot of room for vendors and service providers.
From a corporate perspective, we will observe approaches where companies fully rely on IaaS, putting everything into the cloud. There will be companies which use just some cloud services, like federation or strong authentication. And there will be companies which still mainly rely on their own IAM and GRC infrastructure, with the need to integrate that with cloud services they use.
Today, you can’t fully rely on IaaS but enhance your IAM and GRC infrastructure with some very interesting solutions to become more flexible in your move to cloud computing. But you definitely should analyze which opportunities IaaS provides – and how to do IAM and GRC for cloud computing, Enterprise 2.0, Web 2.0 and all these other initiatives.
Not to forget: I’d like to once again ask for your participation in our current surveys. Thanks!
06.05.2008 by Martin Kuppinger
These days I have had a briefing with John De Santis, Chairman and CEO of TriCipher, about the new myOneLogin service. This service provides strong authentication and Single Sign-On for SaaS applications, supporting many SaaS apps as well as features like SAML-based federation to the few SaaS providers which are already at that level.
One of the things John mentioned was that Salesforce.com has allowed Google to be the authoritative source of identity assertion. In that relationship, Google is acting as identity provider. Besides the question whether Google is the best choice to trust on that leads to another question: There is no established identity provider in the so called “cloud” [By the way: Has the term "cloud" been chosen because everything out there is a bit "cloudy" in the sense of "fuzzy"?].
Read the rest of this entry »