A Standardized Open Source Network Authentication

JigSaw writes "The open source community has mastered many challenges and has been successful in numerous areas. However, there is one glaring weakness that needs to be remedied. Without progress in this area, open source in the enterprise will always play second fiddle to Microsoft, Novell, and other corporate computing entities."

Comments

Dumb question

[Anonytroll]

What about PAM?

The problem is for windows...

[curious.corn]

... it's the poor sap that doesn't have a standard openly documented distributed login system. It's also quite difficult to implement one given that Microsoft knows damn well how crucial it is to possess this part of the infrastructure; otherwise they could have done like apple (OpenLDAP + Kerberos5). They chose to break the stadard (or at least attach undisclosed extensions) in order to remain in it's current 'rabbit' status and make pretty damn shure nobody breaks free of the straglehold (making the authentication interface poorly documented and rather mpossible to substitute without dramatic loss of functionality) Would it be difficult to write a fully working LDAP + Krb5 auth plugin for Windows? I've never seen one... except for the Novell one, and it's not free...

Re:The problem is for windows...

[duffbeer703]

That's a non-problem. Windows comes bundled with an robust, easy to use if not "standardized" directory and kerberos implementation.

If you want to use a "standard" implementation, you can buy identity management software or use something like this http://pgina.xpasystems.com/.

In any case, the problem with "standard" LDAP/Kerberos implementations is that they are nearly undocumented.

Ask a skilled NT admin to setup a test domain and he'll be back before lunchtime. Ask most skilled Linux admins to setup a test LDAP/Kerberos5 domain, and he'll be back in two weeks with the project half-done.

Deeper problem

[Twylite]

The problem goes deeper than authentication. Those familiar with Win32 service development should be aware that pipe communication (including SMB used for file sharing) "transparently" communicates the security principal of the caller, so that the service can impersonate the calling (temporarily reducing its effective permissions to those of the caller).

This is incredibly powerful, as it allows a service to seamlessly integrate with operating system (and by extension enterprise) security, without the service developer needing to reimplement access controls, or implement a new access control system.

What we need is a generic communication layer that includes:

• Transparent channel setup, including exchange of credentials and initialisation of security parameters for integrity and/or confidentiality
• A message-oriented protocol. Message-orientation can provide huge benefits in terms of security, especially if you have a standard daemon/service that handles message receipt and verification before passing it to "third party" code. Such a service can act as a first line of defense against buffer overflows and other data corruption attacks.
• Allow the service end to impersonate the credentials of the client (temporarily drop permissions), so that there should be no need or excuse for any application to have to invent or implement its own access control system.
• Provide sufficient hooks and feedback to allow the user to offer alternative authentication, prevent authentication (force anonimity), or reject the authentication of the server end.
• Is extensible without being ridiculous. The need of certain frameworks to support 10 or 20 cryptographic mechanisms on the server is ridiculous. It makes servers bloated and difficult to develop. At any point in time only one well-considered mechanism is required per desired outcome (e.g. one sign-on and symmetric key negotiation protocol, one symmetric encryption and message authentication protocol).
• Is easy to use in development. Complex frameworks, as a rule, are complex to use. Thus developers have a preference for reinventing the wheel, because a wheel is easy to understand, whereas a pneumatically endowed polybutadiene sheath of configurable pressure attached to a transverse axis situated at the vertical midpoint of the supporting plane and the bottom of the cart isn't quite so clear.

But that's just my 2c.

NDS

[4of12]

So why not make NDS more freely available?

Now that Novell has invested in SuSE and Ximian, go full steam ahead in the Linux market, why not bring out Novell Directory Service across platform?

IIRC, Novell had NDS ready years ago but were pre-empted by a vaporware announcement of AD from Microsoft. Corporate clients were wary of buying NDS, even if it was a nice product, just because they knew that in a year or two MS would come out with their own brand of directory service that would be tightly integrated into other MS products.

Either do that, or have Samba 4 include more of these combined directory authentication services, hopefully using standardized components such as LDAP and kerberos.