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 »
26.11.2007 by Martin Kuppinger
These days I have written a report on the relationship between IAM (Identity and Access Management) and SOA (Service oriented Architecture/Applications). One major aspect of this relationship is around end-to-end-security, e.g. securing the interaction of a user with an application (and the application which implements a business process) up to the backend systems like databases.
That is inevitable because using a service in the context of an user identity or an user role is the only way for consistent, externalized security instead of coded security where some return of a service is filtered by the application depending on the user’s role. Coded security is contradictory to compliance, obviously. It’s expensive in terms of coding and auditing. Thus, it doesn’t make sense.
On the other the most common approaches for web service security are constructed the same way as web access management solutions: Building a layer in front of the services which uses policies to decide how services are used. That includes some part of authorization and sometimes authentication. The problem is: Using such an approach means that there is definitely no end-to-end-security. From my point of view, there is no alternative to federation to transport claims down to the service level. That is the only approach for real end-to-end-security and thus for applications which are architected to fulfill the increasing compliance requirements.
22.11.2007 by Martin Kuppinger
Have you ever thought about assigning the IT costs in a correct manner? Services and IAM will help you. Services are a means for a more granular view on what IT provides. That is true as well for the IT infrastructure services which are, for example, covered in ITIL. It is true as well for the services used in SOA concepts. But services aren’t sufficient. The assignment of IT costs requires the knowledge about the user. Who is using which services in which frequency? This question has to be answered as well. That means, that you have to know in the context of which user a service runs or – more abstract, for infrastructure services - is used.
Thus, bringing IAM and BSM together and combining IAM with SOA is the foundation on which a more efficient IT cost management could be build. And it is, as well, the foundation for the thing I would call ERP for IT.
15.11.2007 by Martin Kuppinger
One of the emerging topics in the broader IAM space integrates GRC and Identity Management: Identity Risk Management, including aspects like Identity Risk Metrics. Identity Risk Metrics are used to measure specific aspects of Identity Management. These metrics can be mapped to risks and thus serve as a means to detect and, in the next step, reduce risks. Such metrics can be defined in many areas.
May be the most interesting are Application Risk Metrics – in the context of digital identities. Elements of this category are things like
- Usage of central identity stores (instead of application specific identity stores)
- Sensitive attributes in decentralized identity stores
- Sensitivity of the application and its data
- Supported authentication mechanisms and their strength
- Number of user accounts
- Encrypted storage of passwords
- and many others…
The analysis of these Metrics automatically leads to a clear view on the level of centralization of Identity Management and, combined with the risk view, to a clear rating of risks which exist due to decentralized user management on the application level and the lack of an application security infrastructure.
Measuring these Metrics can clearly lead in more management support for building application security infrastructures and changing the way security is implemented in applications. It is not very difficult to do this sort of analysis. It doesn’t need a specific Risk Management software, it is just about identifying the applications (which is the hardest part) and counting – and may be some analysis in Excel. And it is about mapping the result to defined risks and to provide an answer on the question of “how to reduce the risk”. The answer is quite obvious – it is the approach of application security infrastructures.
And that is just one example of what you can do with Identity Risk Metrics.
22.10.2007 by Martin Kuppinger
In some of my last entries in this blog (here and here) I’ve mentioned the concept of Enterprise Information Management, something I will cover in depth in a report within the next few weeks. Enterprise Information Management will be sort of the long term evolution of today’s Identity Management and some of the tightly related topics, as well as the integration of IAM with some other technologies. I started thinking about this concept when I developed a simple chart which describes the future of IAM.
It starts with today’s IAM, which is sort of “Identity Management for Administrators”, e.g. solving mainly technical issues in synchronizing information, with support for single sign-on or with provisioning. I’ve titled the next level “Identity Management for Applications”, describing the service orientation and the integration into applications. It includes aspect like Application Security Infrastructures. Many vendors are working on a service layer or the integration of business applications with their IAM products.
Read the rest of this entry »
|
 |
Services |
|
 |
Subscription |
|
|