How come open source applications that are targeted at enterprises, don't have these security features?

Question

1. It would seem to me that many large enterprises already have robust directory services such as Active Directory and it would be silly to constantly duplicate users in an application-specific store.

2. Even if you require duplicating the user store, you can provide a mechanism to authenticate against Active Directory. Alternatively, you could support a standards-based SSO mechanism that leverages SAML.

3. Support for the XACML protocol. Duplicating information on roles and entitlements is equally insidious.

4. Support for the SPML protocol. Many enterprise leverage identity management toolkits and would at least like out of the box integration in terms of centralized management and provisioning.

So, why aren't open source projects considering this type of functionality as a default to getting on the radar within an enterprise context?

Answer 1

Lots of reasons, but one of the biggest is that there's less convergence on what the right or best methods really are than you seem to believe.

• Active Directory, for example, is kind of notorious for presenting implementation difficulties to non-Microsoft developers.

• There are probably a half dozen competing single-sign-on "standards".

• It's very difficult to reconcile different roles/privileges models -- hell, Sun has trouble reconciling the models of Solaris Trusted Extensions with the Java model.

• Solving those problems isn't a lot of "fun" and so FOSS developers are attracted to other issues.

Answer 2

I think that Charlie nailed it:

solving security problems is hard and generally not a whole lot of fun

OSS developers tend to be all about enjoying what they are working on. I work on a number of "enterprise class" efforts as part of my professional life and I will agree that they are not a whole lot of fun. However, this is one of my never ending griefs with OSS components... we have trouble using them in our solutions because they do not meet our customers needs.

I think that the general reasons are:

• universities tend to ignore this aspect of "enterprise development"
• too many standards to choose from
• no clear market leader
• the different security providers are difficult to configure and test
• the entire application security paradigm requires a lot of expertise before you can even start trying to integrate

Personally, I blame the first one. Most engineers do not even consider how an application can be used in a larger context. They are interested in solving the problem at hand and not at all interested in providing a usable solution. Most FOSS solutions are very much an interesting solution to an interesting problem. A corporate entity normally comes along and provides the commercial packaging that makes the FOSS solution actually usable in a real environment. Of course, this packaging comes with a price tag attached.

Answer 3

Open ID is a start towards providing an "authentication" solution. (To the best of my knowledge, it has no "provisioning" mechanism, though. You have to trust the external authority to identify an account, then add your site's / app's version of that account using your own devices)

If anybody knows of some kind of open "authorization" solution to centralize the management of roles, that would be interesting as well. That sounds like the sort of thing you would do in-house, though, with roles that have a defined meaning in your organization. I'm sure IBM or Oracle would be happy to take a big chunk of change and make something for you, though :-)

Answer 4

You may not want to have your active directory / LDAP contains the role of all your users for all your applications. If you have a lot of movement in your structure, you may have a lot of daily modification going on.

Also, the information in the user store may be quite specific, and may not have its place in a global repository.

Least, the notion of role can be quite variable. We have three application that possess the notion of "mananger", each one having a slightly different definition of what is a manager and who he/she is managing.

regards, Guillaume