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 »

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.

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.

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.

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 »

A side effect of application security infrastructures

When writing my upcoming report on the architecture of application security infrastructures I thought also about potential business values of this type of service layer which sits between applications and the security infrastructure (in fact the term “application security infrastructure” is somewhat misleading because its more about a service layer which sits on top of the infrastructure - and the service layer is core, not the infrastructure). When thinking about the business values it became clear to me that there is a clear link to what I have written in “The ERP for IT” about the chance to use service orientation for making IT sort of a business unit.

Application Security Infrastructures can support IT to become more business-oriented and more economic. How? Very easy: These infrastructures expose defined services (security services, mainly identity services) to applications and network infrastructure components (for example “identity storage services” as interface to directories). The usage of these services can be measured. The costs of the underlying infrastructure can be measured as well and is related to specific services. So, in effect, you have the cost per use per service.

With that information you can for example predict the costs of new applications much more precise than before. You can assign the costs of the infrastructure much more precise than before to the consumers of the services. You can offer more efficient services for lower costs. And so on… IT can act like a business unit or, more familiar, like an “internal outsourcer”.

That is, from my point of view, one of the biggest advantages amongst the pretty long list of business values an application security infrastructure can deliver. For sure that isn’t unique to application security infrastructures, but applies to any move towards service orientation.

In the last week I had several conversations with different IT vendors and end users which led to a discussion about the value of identity services within a service-oriented architecture. The IT companies came from different market segments. One example is E2E, a swiss company which develops a tool for model-driven architecture and the resulting applications. They have started defining such identity (and other security) services within their models. Other persons I spoke with came for example from the BSM (Business Service Management) space.

The well-known business values for identity services within a SOA concept are mainly the ability to not only build business processes but to build secure business processes and the reduced development costs. The latter is true because it is more efficient to use pre-defined services instead of reinventing the wheel of security for every single application (and, to note, to reinvent something which usually has five edges instead of being round…).

Another point is that there usually won’t be “compliant” applications without a set of pre-defined identity services - the alternative often is to code at least some aspects of security, even in applications which were developed with the SOA concept in mind.

That leads to one other real big advantage of identity services: They make software audits much easier - and thus avoid some of the struggles you often observe between the security guys and the application developers. With a consistent service-oriented approach and the use of pre-defined identity services, software audits become much easier. You only have to audit a version of a service once. Afterwards, it’s only about analyzing the “orchestrated” application models and the additional code. When security is delivered through services, you have much less to worry about when doing software audits. Besides, the audit of changes becomes much easier - you have to either analyze the changes in services or in the applications itself. By the way: The more these applications are really model-based and orchestrated and the less custom, application-specific code there is, the easier are software audits.

The guys from E2E told me that in some case they could reduce the time for a software audit from 4 weeks to some 36 hours. Even while the effect isn’t necessarily that big - there is a clear, positive effect. And it is an effect in terms of money, in terms of time and, given this, sometimes even in time to market. May be the biggest effect is that identity services makes you the developer’s best friend through reducing the pain of software audits.