Challengers: Forgerock

One very interesting trend over the last couple of years is the rise of a number of challengers in the IAM space that has unsettled the oligopoly of IBM/Oracle/CA. Sailpoint, Aveksa and Courion keeps scoring very well in the waves and quadrants but there is also a number of smaller companies that simply don't have the market presence to be noted by Gartner and Forester and I thought it could be interesting to take a look at some of the companies that I think have an interesting viewpoint or interesting products.

First up is Forgerock. Forgerock largely consists of ex Sun employees that left during or just after the Oracle take over. Forgerock has managed to pick up some of the very brightest Sun talents as well as some of the most interesting concepts and ideas from the now defunct Sun IDM community.

Forgerock's main differentiator is the fact that their products are open source. The company has also been very good at leveraging various open source products as a part of their platform which has resulted in the creation of a quite rich product stack in a short period of time. The open source philosophy plus a very impressive list of implementation partners also means that the long term product support is safe which is one of the major issues with buying an IDM product from a small player.

The stack consists of four major components:

• OpenAM
• OpenDJ
• OpenIDM
• OpenICF

OpenAM supplies or will shortly supply most of the functionality that you would like to see in an SSO product including federation and risk based authentication. The product currently supports an agent based approach for policy enforcement with a reverse proxy becoming available during Q1 2012.

OpenDJ gives you a competent Java based LDAP server with a very interesting web service interface.

OpenIDM offers a very flexible provisioning platform with lifecycle events, workflow support (BPMN 2.0 based), password synchronization, self service interface as well as auditing and reporting support. The main strengths is the flexibility and modularity offered by the OSGI based framework.

OpenICF is a framework to create connectors with a quite impressive list of currently available connectors.

If you look at the components the main strength is that they are Java based, very flexible and service oriented from the ground up and has integrations with some very interesting open source products. There is no legacy core that consists of tons of magic built on top of a data model with three letter table names or a huge install footprint (you all know what products I am talking of).

The main issue with Forgerock is the same thing that doomed Sun. It is a technology and engineering driven company that builds excellent products which is great if you are an end user company is mature enough to take a flexible platform and shape it to what you need. Forgerock has managed to cultivate a very impressive list of implementation partners but most of the partners are small boutique shops. Most of the products still need a bit more depth and lacks flashy user interfaces so if you are looking to implement an IAG solution or a massive cloud provisioning solution against a very tight timetable you should probably look elsewhere.

On the other hand if you are a technologically mature company or are comfortable with trusting a system integrator to do your technology work for you Forgerock offers a very competitive IAM platform that can be customized to fit your needs without breaking the core application. In the end it is much easier to build a nice front end for a stable, flexible and strong back end than doing the reverse exercise.

IAG magic quadrants and no more Tivoli

A new year has started and as all new years 2012 will certainly bring some interesting new changes.

Gartner published their new Magic Quadrants and this year they invented a new one in the form of "Identity and Access Governance". If you want the report you can get it from Sailpoint. The report really doesn't contain very much information that wasn't made public in the Gartner IAM summit back in November.

Aveksa and Sailpoint continues to lead with Oracle just behind them. It is really fun to see smaller vendors unsettling the larger players. The main surprise is probably that IBM is totally out of the race with essentially no products at all in this space.

I would say that this is not entirely accurate as you can achieve the same functionality as in Sailpoint or Aveksa using a combination of ITIM, a custom request and approval front end and the new IBM Security Role and Policy Manager (IBM RaPM). This would of course require a lot of work so clearly for most new customers the Sailpoint or Aveksa solution looks quite tasty and it is clear that IBM has some catching up to do.

IBM is also renaming most or all their Tivoli products and making their latest acquisition Q1 labs the centerpiece in a new security group. Using a SIEM tool as the center of your security suite is a novel idea and the Q1 user interface is very slick so this may be just the right move for IBM.

The name change will make googling for Tim and Tam information substantially harder as IIM and IAM are already kind of occupied. Makes you long for the good old days of 2011....

IAG vs provisioning

November has been a very busy month which has resulted in very few posts.

A part of the busyness was a trip to San Diego to visit the Gartner IAM 2011 conference. Overall the conference was great fun and I met lots and lots of old friends. Going to IAM conferences is a bit like going to a high school reunion. The food was also excellent and as the conference was held in a small hotel I actually got to go outside and get some fresh air every now and then. This is a rare luxury in the standard Las Vegas located gathering.

In my opinion the overall trend was a continuation of the direction that was announced in last years Gartner IAM magic quadrants. You could also see the same trend in the Forrester Role Management and access recertification wave. The concept has gotten a brand new TLA in form of IAG (I still like RMAR) and will now have it's own little quadrant.

So what is IAG? Well the core concept revolves around the simple fact that it seems to be very hard to get ROI on conventional provisioning driven IAM projects. In theory IAM projects are supposed to provide ROI based on the fact that they lower operational costs. In practice this has turned out to be an illusive goal.

As we all like to stay employed we now have to figure out something else to sell to the business and this new is now service catalogs, access recertification, transparency and governance. The core user needs to switch from an IT department gnome (a.k.a. the sysadmin) to the actual business users.

What does this mean for the applications? Primarily it means that they need to be prettier and easier to use. The Amazon shopping cart analogy seems to be very popular for access requests as well as credit score like risk assessment numbers. Access recertification as well as approval workflows needs to be very appeticing as well as easy to use by non IT users. Enterprise role management seems to have fallen out of fashion and we are back handling entitlements albeit nicer named entitlement with better tans (i.e. no AD group names like fap0503dfg).

The current leaders in this space seems to be Aveksa and Sailpoint but the big boys are starting to notice and are trying to catch up. IBM has some very interesting stuff coming out very soon in general availability in the role space (although they may change the branding of that specific functionality now that roles aren't cool anymore). Oracle just updated Oracle Identity Analytics and I am sure that there is more to come soon.

Forrester security forum

It is gearing up to be time for the Forrester security forum but as per usual I can't attend as one of the disadvantages when you have a wife who chairs an event is that you kind of have to stay at home and take care of the kids. If I would be able to go I would be interested in the following talks:

I am interested in what Chenxi Wang's talk about "Securing The Extended Enterprise — Protect Your Information Anywhere, Anytime, And On Any Device" is actually going to contain. It is always good when you get intrigued by the talk abstract. Is she going to talk about BYOD for mobile devices? Or is she setting the stage for Andras Csar and Eve Maler?


Andras will probably continue the very strong (in my opinion) line of reasoning around access governance that he laid the groundwork for in the Forrester Role and Access Management Wave but focusing on social networks. Authorization in social networks is not an easy task and if you add that the user identity may actually reside in another social network and you might just have a federated user object to authorize on the problem becomes even more complex.


My guess is that Eve's talk on "Securing And Identity-Enabling Monster Mashups" will focus on OAuth and I think that is a story that really deserves continued spot light. I recently watched a webinar where Eve was one of the speakers and OAuth clearly can be used in very interesting ways to lift the security of the internal as well as external ESB to not only support authorization on the service account level but to take the authorization to the internal user or even end user level.


There are also some very promising keynotes. Scott Gerlach's piece on how to involve your customers looks really interesting. I and most info sec professionals normally have problems with even involving the business in IT security so getting the customers engaged is clearly a new and interesting perspective. The Diginotar affair has not really gotten very much attention outside of nerd circles so I am very happy that it is being talked about more. The CIO-CISO Partnership: Partnering To Protect Our Customers is another good keynote topic with really promising abstract.


Full disclosure note: The section at the start of this posting was not a joke. I am married to Laura Koetzle who chairs the event.

XACML training workshop in Washington DC

On September 19-20 Axiomatics will be arranging an XACML workshop in Washington DC. I will be there and perhaps I will meet some of my readers.

In my opinion the most interesting aspect of this workshop is that Axiomatics' has managed to establish a fully featured ecosystem around their product. I started looking at the product back in 2009 and at that point it was a useful and very interesting PDP.

The use case I was looking at was online health records for usage in pre and post FDA approval registries and given that Axiomatics had been used in the national Swedish healthcare implementation they had the substantial edge in that the system actually was in production. The main issue with Axiomatics at that point was that getting access to the rest of the pieces that you would need for an actual production implementation would require usage of components that were built or heavily configured by companies that really didn't have any global delivery capability. If your needed the stuff delivered on the Nordic market then it worked fine but if you needed it in the US or Asia Pacific you basically  needed to use another products.

Over the last three years Axiomatics has managed to pick up some really smart people including Gerry Gebel from Burton group. Gerry and the rest of Axiomatics has worked really hard on establishing connections with other product companies whose products fits very well with the PDP as well as professional services organizations that can manage the implementation.

The result of this work can be seen in the speakers list for the XACML workshop. Sailpoint will be there to talk about how you use Sailpoint IdentityIQ to not only provision users to the central user and attribute repository, perhaps an LDAP server from Radiant Logic, but also manage the entire lifecycle of the user including access recertifications. You have Layer7 that talks about how to integrate Axiomatics into your corporate web service gateway or your enterprise SOA platform. Well done Axiomatics!

RMAR is the word!

If you have been in the IAM space for a while you kind of recognize the waves that regularly hits the industry. One example is the provisioning wave that started picking up speed back in 2004-2005 when most provisioning vendors were simple startups with a few customers and rather rudimentary products. Over the next 24 months each major player (IBM, Sun, Oracle, CA) built or acquired a product in the space which in turn meant that suddenly the sales and marketing resources that were available to sell the products increased by a factor 10-100. Unfortunately the delivery capability of the professional services organizations didn't really grow as fast which lead to some "unfortunate" implementation projects some of whom I was part of.

Go forward a couple of years to 2006-2007 and the hot product is now role management. The same pattern plays out again. Sun buys Vauu RBACx, Oracle buys Bridgestream, IBM stays on the sideline and uses partnerships. There are a couple of independent players that aligns to the big boys (Aveksa, Sailpoint) but when the economy started to fall apart things started to look bleak for the independents and they were forced to shed staff and to cut down on R&D as their customers no longer could afford to start new projects or even keep already initiated projects moving.

A few more years forward and we are now in mid 2011 and Forrester is publishing a new and shiny Role Management and access recertification wave (get it at Sailpoint) that places Aveksa and Sailpoint as the leaders. Certainly not the result I would have expected back in 2008 so I would like to congratulate both Aveksa and Sailpoint to their placement. They have done a very impressive job and shown that a relatively small independent shop can outperform the big boys. Well done!

One major change in the market place is that the role management and access recertification is getting more and more exposure as a central part of any IAM strategy. Gartner prefers the term IAI (Identity and Access Intelligence) and our Germanic friends at Kuppinger Cole uses GRC (Governance, Risk and Compliance). Andras actually doesn't coin his own TLA or eTLA in the report which I am very disappointed about. Doesn't RMAR sound like something that would conquer the world?

The Forrester take on the subject is that:

As a security and risk leader, if you only have one dollar to spend on identity management, spend it on access governance.

Undoubtedly a very strong endorsement of the area that will result in lots of end user companies spending even more money in this area.

If we look at the competitive landscape what does this wave mean. Sailpoint and Aveksa are of course going to get a very substantial boost. They both have really good and mature products so I am not so surprised that they fared very well.

When it comes to the players that fared less well I am not surprised at all about IBM's ranking. IBM is in the process of bringing a brand new product to the market and their current offering really is close to non existing. I got a sneak peak at the new IBM role manager at Pulse this spring and I am quite convinced that IBM  will be a top player once this hits the market in later 2011 or early 2012 but at the moment they deserve the scoring.

I am in a way surprised about the Oracle's scoring. Oracle has been trying to come up with a viable offering for a long time and after a couple of false starts (first an internal product that was killed before hitting the market, then Bridgestream/ORM (which was killed after a quite bad showing in the market) they finally got a good product in form of OIA (ex Vauu RBACx, ex Sun Role Manager). Perhaps the many name changes of the product gives a clue about why it no longer is a top notch offering? If you take a good product and spend a couple of years integrating it into a major IAM vendors stack (Sun) and that then promptly gets acquired by another major IAM vendor (Oracle). The new owner spends another couple of years integrating the product into their stack and at the end the world simply has move on and what was a good product is now just run of the mill.

The most interesting conclusion is perhaps that the era of when the base for any IAM strategy was implementation of one of the huge provisioning centered IAM stacks (Oracle, Sun (RIP), IBM and CA) may be over. Perhaps we are entering a world where provisioning isn't the center piece and where the independent players takes a bigger part of the market? Another alternative is of course that Larry gets fed up and buys Sailpoint, CA buys Aveksa and the IAM stacks gets one more mandatory component.

(Full disclosure note: my wife was one of the editors of this report)

IAM project painpoints

In my experience IAM projects generally have severe pain points in three areas:

1. Processes
2. Data
3. Technology

On the processes side it is often unclear if the new system should reflect how things should be done or how things are actually done. You also have the built in conflict between operations (things should be done as simply and straightforward as possible) and audit/compliance/security (the processes should provide adequate
safeguards). One safe way to fail an IDM project is to not get your processes defined and accepted by the key stakeholders at an early stage of the project but rather discover this issue during UAT.

If your data is dirty it doesn't really matter how good your provisioning and/or access logic is. Data ownership is often a huge issue as the owners, if they even exist, usually are blissfully unaware of how bad the data actually is. Data issues are interesting because there are lots of different kinds of data problems. In some cases the data lacks clear referential integrity between different systems which will hit you during initial load. Another data issue that may surface if you use user names to generate things like logins and email addresses is that names can cause problems. In many cases you need a reporting structure to be able to communicate to the users manager. If you don't really know who the manager is, which isn't that uncommon among contractors then you will have a problem.

Finally the technology part is about having a vendor that has experience on not only standing up the technology in itself but also to integrate it with the target applications. It is not uncommon that you spend 2-3 weeks on implementing the technical part of an integration the first time you do it while it takes you 2-3 days (or even 2-3 hours) the second time. Experienced high quality technical resources are key to have a quick and efficient implementation but right now there are many more projects than qualified engineers and architects.

JIT provisioning - the compliance view

JIT provisioning gives you significant advantages in operational agility as the cost of integrating provisioning to an application, measured in time and effort, becomes a lot smaller than with the conventional provisioning approach. As always there is of course downsides with JIT provisioning so lets talk about the issues and how to mitigate them.

The reason why provisioning systems exists are basically to make onboarding, offboarding and maintenance of the access profile of the corporate user more efficient. The efficiency gain comes partly from automating the actual provisioning and deprovisioning operations and partly from automating compliance activities (who has access to what). It is clear that JIT addresses basic operations in an efficient manner but what about compliance?

Conventional provisioning systems offers the ability to see what a user has access to and also why the user access to these resources. The answer to the why question may be that "because the user in an employee the provisioning policy dictates that resource X should be granted" or "the users manager raised a request for resource Y and the resource owner granted it". Some provisioning systems also supports access recertification ("on May 15 2011 the users manager thought that the user should have access to resource Y"). The access information is often exposed through reporting functions and/or a pretty web interface so auditors can get the information they need without having to understand the inner workings of the provisioning system.

In the JIT world things get a bit more complex. In essence the authorization is based on what the guy on the other end is claiming to be true. In it's simplest form anyone who comes over from the partner application would have full access to your application. In a more complex situation you may have the partner sending you either raw user information attributes (user y is in cost center x) or some form of role attributes (user y has the role of broker level two). The application then makes an authorization decision based in this information. This two tiered authorization model makes the auditors life substantially harder but there are ways to increase transparency (i.e. use XACML instead of embedding the authorization decision in code).

Even with transparency measures in place a nswering the questions "who has access to resource X" and "what resource does user Y have access to" becomes really tricky in a JIT world. If you also need to answer the why questions you are in real trouble. It is going to be really interesting to see what vendor in the access governance space will be first with addressing this need.

JIT provisioning - the application view

In JIT provisioning I looked at how you could create a just in time provisioning system. In that posting I discussed the case from the identity hubs point of view. Now lets take the other viewpoint and be the app instead.

As the app you basically have made the choice to trust that the identity hub has done a good job of doing the authentication and authorization. You don't really have any other choice than to trust the hub. If you are an application that doesn't need to persist state between session your life becomes very simple. You serve the content based on the information provided in the request.

On the other hand if you need to persist state you basically need to create a new account every time someone with a new primary key attribute shows up. You would also need some kind of mechanism to invalidate accounts that haven't been used for a while as you would otherwise just accumulate active accounts indefinitely. The disablement could be done through straight ageing (no usage for one month results in the account being put in disabled status or perhaps even deleted) or by querying the identity hub. The query could either be a delta recon (what have been disabled/deleted since I last asked) or a full recon  (get all accounts from the hub and see what accounts are present on your side but not on the hub side).

One interesting aspect of this is that in a company to company situation it should be of interest to the hub company to be able to show the application partners what the hub authorization logic really is as they are in fact trusting the hub blindly. This is a very interesting use case for XACML as it is much easier to review some XACML than hundreds or even thousands of lines of Java/c#.

JIT provisioning

Lets take a break from the check lists and take a look at another interesting subject: Just In Time (JIT) provisioning.

Over the last couple of years SAML has emerged as the defacto standard for federated authentication and authorization. If you are working with a partner the first question is usually "Do you support SAML?".

Incoming SAML makes it possible to essentially outsource the process of authentication and authorization to a business partner. The partner vouches for the identity of the user and you can essentially use this information to give the user access to your system. This solves the run time but in most cases you still need a "back channel" provisioning process. Getting a SAML assertion telling you that the user "msandr01" would like to log in to your application  logging is good but most application needs more information to create a working system account.

Nishant Kaushik published a very good four part series of blog postings on this subject about a year ago that I highly recommend. I ran into the problem in a discussion at Wisegate a couple of weeks ago and I am also looking into the problem for a couple of use cases at work.

The use case we talked about at Wisegate was a bank that had outsourced all of their customer facing applications to various vendors. One vendor did retail banking, another brokerage, a third investment banking etc. All of the different vendors had their own user repositories and own SSO solutions so a single bank customer could have multiple logins and multiple passwords and would have to login to each application separately. The business of course didn't like this and wanted an SSO solution.

The true high tech JIT solution would be to use a federated authentication product such as IBM TFIM and do SAML with the apps all in run time. The hub would be truely light weight and not persist any information about the users. A typical user interaction with the hub would look like:

1. Take the request from the user
2. Figure out which application this user is trying to login to
3. Figure out if the user has any account in any of the apps by asking the apps
4. Authenticate the user
5. Authorize the user
6. Create the SAML assertion and send it to the app
7. Act as a reverse proxy in the interaction between the user and the app

In theory this is a great idea but there are some practical considerations.

One issue is latency. Given that this is an online person facing transaction the login should ideally not take more than three seconds (or so) and if we end up pushing 10-15 seconds the business will start screaming. The SSO hub and the apps are physically in different places which means that you will get latency even if you have lighting fast machines that process the requests.

Another issue is complexity. This does require quite a lot of bleeding edge technology and there are plenty of things that could go wrong.

In the end the discussion ended with the conclusion that it is probably safer to go for a more conventional approach where user populations of the apps are reconned back to a central repository in the SSO hub using a meta directory product. SAML would still be used to communicate assertions to the applications but this solution is a lot faster and eliminates a lot of the unknowns. This solution pattern is very common among a number of vendors including Symplified.

Not as high tech and cool but is guaranteed to work and won't cause hard to fix latency based performance problems .

Checklist manifesto part two - requirements gathering

This posting is a continuation to Checklist manifesto. In that post I discussed how the concept of checklists can be applied to IAM projects on the overall delivery methodology level. Lets talk a bit about how check lists can be used in the different parts of the delivery methodology.

Lets assume that you are using a classical waterfall. This gives you the following steps:

1. Requirements gathering
2. Design
3. Implementation
4. Test
5. Go live
6. Maintenance

In this post I will focus on how you would user checklists in the requirements gathering phase.

One thing I have noticed over my IAM implementations is that if you take a use case driven approach it seems like most provisioning projects will contain almost the same use cases. Depending on how you slice and dice your cases and what your scope is you usually end up with 30-50 core use cases which tend to cover the same subjects.

The use cases may be very different as each and every company seem to like to do things their own special way but you will cover the same overall business process.

This means that a mature implementation organization should be able to come up with a list of use cases that can be given to the more junior resources that will perform the actual requirements gathering. If you are a customer I would definitely include this as a question on the RFP. If you are a junior resource I would speak to your seniors and check if they don't have a list of use cases on their hard drives or if they quickly can create one based on their previous projects.

More about my experiences in the lovely world of requirements gathering can be found in the post UAT and requirements gathering.

Checklist manifesto

Management books are often boring and mostly not really applicable on your situation so they rarely makes good material for a blog post. A while ago my wife was told to read "The checklist manifesto" by her boss and once she was done with it I took a look and actually really liked it.

The core concept in the checklist manifesto is that there are certain series of rather simple steps that needs to happen in order to perform a complex process. The core example is the surgery checklist but Atul Gawande (the author) also uses examples from other fields such as aviation.

Can this principle be used in identity and access management projects? I would say definitely yes.

Good examples why checklists are useful are my two first IAM projects. In the first "first project" I basically had no clue on what I was doing neither on the process side nor on the technical side. Luckily I was in a very junior position so my lack of knowledge didn't doom the project. Interestingly many of the senior resources also didn't have any knowledge of the product but luckily the client realized this and hired a very seasoned person straight from the product manufacturer who managed to get the project back on track and utilized the quite impressive domain knowledge of the senior resources to create a very good solution. The project also managed to pick up some very talented technical resources along the way which helped quite a lot.

In my second project I had a very senior role. In fact I really wasn't ready to take on the role and the project suffered from my lack of experience. We as an organization also had some other issues that we had to work out and in the end I as well as the organization ended up being much stronger but it took a lot of hard work.

In both projects checklists we ended up creating checklists. In the first the main contractor already had a semi formal checklist for how to run IAM projects. They didn't know how to run an OIM project but they applied their general IAM checklist to the project and where decently successful. The initial design that they created was totally unimplementable in OIM but at least they had a design that after a few months of tweaks and changes ended up being implementable.

In the second project we didn't really have any checklists or any form of process until we got some help from one of the senior PMs. He had a general checklist for how to do IAM engagement and we also developed a form of general checklist for how to do offshore development engagements in IAM projects.

Once we had our checklists in place for how to develop, test and migrate the code we could start delivering code that did what the design said it would do. Now the problem morphed to gather the correct requirements so that you can create a design that solves the actual business problem. The requirements and design gathering process is much harder to codify so that was much more of a challenge and it took me a few more years to get to a point where I think I am getting a good handle on that challenge.

Pass through authentication

One of my readers remarked that one the hardest technical challenges is to migrate things that can't be migrated.

One prime suspect here are password hashes. In most well designed systems you don't store passwords in encrypted in a reversible format but rather in form of one way hashes (preferably with some salt mixed in). This means that the only way to migrate the passwords is through mass cracking which usually isn't feasible or at least shouldn't be feasible.

In TDS there is a very interesting solution to this problem in form of pass through authentication. You essentially let the password field be empty and specify that when the user tries to authenticate simply authenticate against the old system. If the authentication is successful then set the new password in TDS. Very good solution and the design patterns can be easily implemented even if your "authentication repository of choice" doesn't support this functionality natively.

Sun set

One of the things my professor in system development at Chalmers told me was to never put anything related to "new" or "next generation" in a system name because at some point the system will be old and will need to be replaced. Having to name the next system "even newer" simply looks silly.

Currently there are a lot of Sun IDM owners that are contemplating upgrading into something that actually is moving forward. Oracle has promised continuing support and probably will deliver, at a steep price, but with the platform not being improved investing more money to add new capabilities doesn't make sense. It will also be harder and harder to find staff that can support the system. I recently heard about a Sun client where the staff had spent three months trying to install a new instance of the access manager agent. The client simply couldn't get it to work and had to give up in the end which of course resulted in some serious angst among the senior leadership as it meant that if the access management agent broke in production the entire application would be out of order for at least an extended period of time and potentially permanently.

We are currently in the final part of the first phase of our migration of Sun and I thought it may be interesting to talk a bit about the experience.

When you do a major upgrade of an IDM stack you basically have two choices. The first approach is to try to do some form of automated or semi automated upgrade. You essentially look at the upgrade as a big patch so you apply the patch in dev and do some regression testing. If everything looks good you start to walk the environments through test, stage and finally prod. In theory this works well and there are even cases when it works in practice (see MIIS to ILM). In the case of going from Sun IDM to Oracle IDM I think it would take a small miracle and a very skilled team to get this approach to work. The product stacks are simply too different and too complex so there is going to be cases where the conversion simply isn't possible. If you also have substantial customizations in play I would consider the approach being close to setting yourself up to failure.

The second approach is to try to leverage as much of your already existing documentation but essentially look at the project as a refactoring exercise. If you have good business requirements and workflow documentation then use that but anything from design and upwards I would strongly recommend that you rework. Most IDM installations don't have good requirements to start with and given that you usually end up creating delta releases rather than updating the original documentation even the ones where the docs where good at one point usually are a victim of "here is the original docs and here are the docs for the 5-30 delta releases that we have put in over the last five years" syndrome.

Update: Identigral's blog recently covered this issue. It is interesting to see that their conclusions are quite closely aligned with this posting.

XACML for eHealth

If you have been reading this blog for a while you may have noticed that I have an interest in XACML and especially in using XACML in the healthcare sector.

If you have similar interests you may be want to take a look at a webinar that Axiomatics will be running on May 5 2011.