Slashdot Mirror


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."

7 of 27 comments (clear)

  1. Deeper problem by Twylite · · Score: 4, Insightful

    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.

    --
    i-name =twylite [http://public.xdi.org/=twylite], see idcommons.net
  2. Re:The problem is for windows... by duffbeer703 · · Score: 4, Insightful

    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.

    --
    Conformity is the jailer of freedom and enemy of growth. -JFK
  3. I agree. by torpor · · Score: 2, Insightful

    Continuously playing 'second fiddle' to Microsoft is no way to develop software. They're counting on this factor, so why should we give it to them?

    Its the age-old argument though. People write code they want to write, in the OSS world, and face it: Networked User Authentication is booo-oooring.

    (But then, I don't see why we don't all use RADIUS and be done with it ...)

    --
    ; -- the corruption of government starts with its secrets. a truly free people keep no secrets. --
  4. Setting up kerberos by yandros · · Score: 2, Insightful

    This suggestion (that kerb5 is so hard to set up) makes me sad.. Is it the kerberos side that's the trouble, or the ldap part (or both, I guess)?

    Back when I worked at MIT, we used to joke about setting up test kerberos realms while holding our breath, it was so easy. I know at least two people who did it, just to prove the point.

    1. Re:Setting up kerberos by beegle · · Score: 2, Insightful

      The problem is the flexibility.

      Kerberos is built-in to most modern linux distros. So is OpenLDAP. Unfortunately, the exact LDAP setup is left to the site. I've yet to see a large LDAP implementation that didn't do a few things with custom fields. I've also not yet seen a site that clearly documents their setup and customizations. The attitude is usually "the next guy can reverse-engineer my work, and that won't be a problem if he's a -real- sysadmin."

      The Windows domain jackboots only give you one way to set things up. That means that they're all set up the same way.

      --
      --
  5. Re:NDS by T-Ranger · · Score: 3, Insightful
    why not bring out Novell Directory Service across platform?
    NDS/eDirectory currently runs on: Netware, Windows NT 4, Win 2k, 2003, Linux RH 7.3+, SuSE, Solaris 8, 9, AIX and HP-UX. I have to think prety hard to come up with a commercial product that runs on more platforms.

    Novell had NDS ready years ago.... But? "Did not ship it?" "others diddnt use it?"... What?. First, it did ship (and is shipping). Many places use it. After Win95 came out and made file and print sharing easy enough for small networks, Novells market has been Very Large orginizations: health care, government, educational instituions. Large corprate clients bought (and still buy) Novell products. Small sites did not stop buying Novell, they stopped buying any dedicated server things.

    Netware 4 (and thus, NDS) was released in 1993. Microsoft server products were (being Very kind) a compleate joke untill NT 4.0, which was released in 1996. AD was not even on the drawing board untill then, and came with Windows 2000, which shipped at least three years late.

    NDS cooperates with Windows just fine (in fact, it can compleatly replace the domain-based security systems). The choice was never Novell servers OR Microsoft servers.... Im sure that a lot of sites looked at it like that, and perhaps you meant to preface you post with "while true or not, a lot of people looked at NDS v. AD as:", I cant allow you to spew off historical FUD.

    Anyway, now to agree with you.. NDS is cool. NDS is very cool. And as much as I like NDS, NDS isnt the answer... The answer is LDAP, NDS is just one of the possible systems that can implement that.

    And NDS is, all things consitered, prety cheep. Current list price is $2.00 per end user... Unlimited installs of the product itself. (MS stuff would be more like $300 per server, plus per-client costs)

  6. Re:standard by walt-sjc · · Score: 3, Insightful

    So you are saying that instead of doing intense security audits and maintaining one system, a system everyone can know well, we should do half-assed audits on dozens of authentication systems and try to maintain them all? The hell with single signon, go maintain dozens of different passwords (or worse, use the same password on everything)???? I don't see how having many disparate systems helps security other than being security through obscurity.