Just in time for Christmas Samba 4.0 was released. This big news here is Samba 4.0 adds Active Directory Domain Controller emulation, including Kerberos, LDAP, DNS, and a bunch of other services.
While this is an impressive technical achievement, I don’t really see many enterprises adopting it. Samba 4 is fighting against one of the biggest IT pressures, headcount reduction. Most enterprises are now willing to pay more for the license cost of the software if it saves them administrative man hour costs.
So unless Samba 4 is going to be easier to install and maintain than Windows servers, it’s not really going to have an impact. Who knows, maybe it will be that easy. If you have Samba 4 in production drop me a comment and let me know what you think.
Meanwhile, Jackson Shaw is … unimpressed.
Posted in AD, Identity, Kerberos, LDAP, Linux, Open Source, Security, Software
Tagged Active Directory, AD, Kerberos, Open Source, Samba 4
I recently saw two polar opposite recommendations; one from Jeff Atwood begging you to not write code; and one from Radovan Semančík suggesting that the only practical software to use is open source software that you can fix as needed.
Obviously Radovan’s approach is not a scalable one. While there are a lot of terrible software products out there, especially in the enterprise space, there are also a lot of good ones that just work. Limiting yourself to coding solutions is a waste of time that most companies won’t pay for. Also Radovan’s solution limits you to open source solutions implemented in a language you are familiar with.
At the same time there are some problems that just need a coding solution, or are best solved that way.
For enterprise solution I am going to thread the path between Jeff’s Scylla and Radovan’s Charybdis by posing these questions:
- How much coding should be expected to implement an enterprise solution?
- How can you find enterprise solutions the works well enough you don’t need the source code or extensive customizations?
An enterprise solution that requires you to write code or scripts to do basic functionality is not well designed, in my opinion. Coding or scripting should only be required wheen the functionality needed is unique to a specific deployment (or too uncommon enough to be a main feature of the product). This is a core philosophy at OptimalIdM as well. Although the VIS virtual directory does support .NET plug-ins, most of our customers never need one. When we have seen the need for plug-ins in the past we looked for a common feature that could be added to the product.
So not having to write code one measure an enterprise solution’s quality. Here are some others:
Ease of install – they say you only get one chance to make a good first impression and install time is it for enterprise software. If your vendor is telling you that you need consulting hours just to install the software, it’s not going to get better from there.
Ease of use – requiring training to use enterprise software is a bad sign. Did you have to have training to use your browser or word processor? Enterprise software should be like that.
Stability – once installed and configured the software should just work. Baby-sitting should not be required. And if you really need two weeks of work or the source code to figure out why your solution stopped working, you made a poor vendor choice.
So go ahead and write code, but only when you have to.
Radovan Semančík has put together an interesting list of open source IdM platforms. There are not as many as I would have expected.
Softerra has released an open source C# implementation of SPML V2 (DSML profile). I haven’t had time to play around with it yet, but it looks interesting.
Now what would be really great would be some developers to take this and create some implementations that do useful stuff. For instance write a service provider for provisioning and reconciling AD accounts. Or perhaps integrate it with Microsoft FIM.
Posted in AD, Identity Management, Open Source, Provisioning, SPML
Tagged AD, DSML, FIM, Identity Management, Open Source, Provisioning, SPML
Nishant Kaushik posits an interesting question; can OAUTH fill the provisioning role in Just-in-time federated provisioning. Mark Wilcox follows up here and here.
I agree with Mark’s commenter who suggests that a SAML attribute service fills the role just as well. Mark suggests that a SAML attribute query is too difficult to implement in some development environments. But I am not sure that I buy the argument that there are environments where doing the SAML SSO is doable but doing the attribute query isn’t.
Regardless all this got me thinking about impedance matching. When we wear our standards hat, all things are possible. But we need to step back at times and put on our developer hat and think about how are designs are going to be implements. While we could mix SAML and OAUTH to support JIT federated provisioning, implementation now requires tools, libraries, and implementers that can implement both SAML and OAUTH as well as handle the rough edges where the don’t mesh well. That’s an impedance mismatch in my opinion.
Posted in Authentication, Identity, Open Source, OpenID, Provisioning, SAML, SPML, Standards
Tagged Federated Provisioning, Federation, Identity, OAUTH, OpenID, Provisioning, SAML, SPML
Luca Mayer has this summary of Sun’s open source IdM projects. I have some experience with OpenSPML (obviously), and I have fiddled with OpenDS. There is some great stuff there.
I hope this all survives the acquisition.
Posted in Identity, Identity Management, Open Source, Software, SPML, Standards
Tagged Identity Management, IdM, Open Source, OpenSPML, OpenSSO, SPML, Sun
Sun (or should I say Oracle now) now has an open source effort for Sun Identity Manager connectors (hat tip to Daniel Raskin). There is even an SPML 2.0 connector listed which is great to see.
This is another shot at the Holy Grail of enterprise management software, getting out of the connector business. It doesn’t matter if you are doing identity management, network management, configuration management, or security management, or systems management, satisfying a never ending customer demand of connectivity to a myriad of systems is a back breaking pain (and expense).
It will be interesting to see how this plays out. There are a lot of Sun IdM enthusiast out there, and many of them are capable of writing connectors. The success of this effort will depend on how many of them are willing to participate in OS projects and more importantly can get their companies buy-in to contribute source code.