[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Tom Brough wrote: | On Fri, 2005-03-11 at 23:32 +0000, Simon Waters wrote: | | Yep but what do you do if you are tied in to "packages" provided by | different vendors that use different digest algorithms for encrypting | passwords ?
If it is FLOSS and the only issue is the digest algorithm that is an easy fix ;)
The problem generally is closed source applications or those that have weird authetication requirements. The classic one is bespoke database apps that authenticate using their own methods against a table. Having out of the box pluggable authentication with MySql and Postgresql doesn't buy you anything for these apps (apart from perhaps an obvious migration path!), because they do their own thing.
| Ok you could put a standard requirement in place, but usually someone | (in management ?) wants it now, not in 10 years time when your last | legacy system is replaced with something that is standards compliant.
If local requirement dictate they want something that doesn't comply they are making their own headache. But I don't think you can dictate these things to a million users, the politics of it would never work.
Beside if you stifle a group from accepting a software package, purely because it needs another password, you'll stifle the development and acceptance of packages, or make the authentication scheme very unpopular.
As I said you need a standards body, but it has to be able to provide assistance in the issues, it mustn't say "no", it must say "could we help you integrate it?"...
| How do you deal with the cross organisation requirements. For example | someone working in social services is most likely to be using Council | Systems, NHS systems and possibly police systems as well. Most likely | packaged systems with no common thread as far as authentication and | authorisation are concerned. For these people its a nightmare to | remember 3 sets of passwords and constantly log on/off systems.
Trust - you just need a way of agreeing trust between the domains. So these users are authorised for this. But this is where I think trying to scale it centrally fails, the number of decisions is just too complex to handle centrally.
|>The technical aspects of the problem are easy, I mean if AOL can do |>it.... I suspect there are probably ISPs out there who authenticate |>similar numbers of users using FLOSS already. | | Single application single requirement single set of standards, therefore | simpler to implement.
I think you underestimate the number of applications that accept AOL credentials - MS Passport would be a similar scheme. Sure a single set of standards, but these things are used for a wide variety of applications.
| How do you deal with different applications requiring different digest | algorithms for passwords and the ensuing need to maintain | synchronisation.
Generally you don't, you mod the apps. Big apps usually have an option to take system authetication, or alternative sources of information, the bigger problem is where the applications store additional data with each account, how do you manage that? Often this data may include permission type data. Guess that is what system integrators are for.
| How does application B know that you have already been authenticated and | authorised via application A ? or is this something in the LDAP protocol | that I am not aware of ?
OpenLDAP will just store data, authorisation is done through other schemes, usually kerberos. This is effectively what Microsoft are doing, although they "embraced and extended" somewhat on Kerberos, and used a proprietary directory (which does provide LDAP access I believe).
In that sense doing this with FLOSS is not so different standards wise as doing it with non-FLOSS. The problem with the FLOSS technical approach is that the most common people doing this are ISPs, so you see a rather warped supply of software.
A good example was when I was looking a few years back for good address book software - a classic use of LDAP, and couldn't find a good FLOSS solution (I think that is kind of solve many times over now), however if I wanted a FLOSS ISP solution I had a choice of "out of the box" packages to do almost everything even then. The one thing ISP customers generally don't need is an email list of all the other ISP customers, so they can email them.
Similarly the ISPs are usually more about having a single set of authentication credentials, rather than a single sign-on, not least you often want to establish the person who started a session is the person who is buying something with their credit card, and not daughter/friend/exgirlfriend/lodger.
Thing I was never convinced by was the use of LDAP for ISPs, last time we deployed we put the data in a relational database, and authenticated from that (again many FLOSS ISP apps can do that - Apache, ProFTP, qmail-sql, PAM (for those apps that can't directly) etc. I think for single sign-on (rather than single authentication details) you may be forced to use kerberos.
Most of the big projects I've heard of, still end up with routine data imports from a directory service being done for some applications, and I guess these companies are the ones you make do the engineering on the understanding you are buying the source code to their "temporary hacks". Often these temporary hacks compromise the security somewhat, which may not be desirable for a lot of government activities.
-----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCMuKLGFXfHI9FVgYRAqdmAJ4n3SN5W6STE3w8VboT1HW/lvG7QwCdFjYQ LDNdoDemKnFfnvg0nO+3yDI= =tC8B -----END PGP SIGNATURE-----
-- The Mailing List for the Devon & Cornwall LUG Mail majordomo@xxxxxxxxxxxxx with "unsubscribe list" in the message body to unsubscribe. FAQ: www.dcglug.org.uk/linux_adm/list-faq.html