Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Single Sign-On for Integrated Open-Source Apps?

Cliff posted more than 11 years ago | from the single-user-mode dept.

Programming 28

maiden_taiwan asks: "We're constructing a free groupware application by integrating well-known open source components: apache webserver, inn news server, ircd chat, scp for file transfer, etc. Unfortunately, each app has its own incompatible concept of a 'user identity.' Apache has the htpasswd module, IRC has nicknames, scp has public keys, NetNews has the poster's email address, and so forth. Has anyone managed to integrate a similar suite of apps using a single sign-on model, where a user has a single identity that is understood and carried through all these apps?"

Sorry! There are no comments related to the filter you selected.

What comes immediately to mind... (0)

Anonymous Coward | more than 11 years ago | (#4678598)

... is LDAP. BTW, fp.

Try this combo: (3, Interesting)

forsetti (158019) | more than 11 years ago | (#4678615)

LDAP+Kerberos (via GSS-API)

OpenLDAP supports GSS-API natively
iPlanet / Sun One Directory supports GSS-API with a plugin.

Do a couple searches on google. Lotsa good info on this arangement.

ldap (1)

iosphere (14517) | more than 11 years ago | (#4678623)

I haven't done it before, but I'm sure you could come up with something centered around LDAP that would accomplish what you're describing. I'm pretty sure there's an apache module for ldap, and I'm betting you'd be able to toss in the public keys for scp and modify the ldap schema with an extra field for irc.

Just a thought...

What are you trying to do? (3, Informative)

edbarrett (150317) | more than 11 years ago | (#4678678)

It might help if you were clear about what you were trying to do. Might the phpGroupWare [phpgroupware.org] project be something to base your project on?

Re:What are you trying to do? (2)

bwt (68845) | more than 11 years ago | (#4679358)

I thought he was very clear.

I don't see how phpGroupWare (which is a great project, by the way) solves the single sign on problem. It only adds another thing you have to sign on to.

Maybe this is relevant: DotGNU VIS (1, Informative)

Anonymous Coward | more than 11 years ago | (#4678764)

Recent post to developers@dotgnu.info from Peter Minten:

a lot is unclear about the DotGNU Common Virtual Identity System (DCVIS or
simply VIS). And with the current amount of active auth coders that's not likely
to change soon. The VIS needs however to be integrated into the DotGNU System. I
therefore propose the following:

* We should create a specification of the VIS.
* These specifications should be used to implement a minimal feature reference
VIS server.

The way I see things there are a number of things to be put into the VIS spec:
* How the VIS server communicates with a webservice
* How a Virtual Identity must be structured (note that this only applies to the
VI send over the connection with the webservice, the VIS server's internal
structure of a VI is unspecified).
* What fields of a VI are mandatory (a field like name should be in all VI's)

After the VIS spec is put up a very basic reference implementation can be
created. The reference implementation can then be used as a testing aid for the
Arch and Auth coders.

My advice (0)

Anonymous Coward | more than 11 years ago | (#4678828)

My advice is to program a machine to do it for you.

We're sorta doing this, but not exactly... (4, Informative)

PhaseBurn (44685) | more than 11 years ago | (#4678834)

We have a MySQL database that is used for e-mail, RADIUS, and FTP logins, and all those records are kept in MySQL... I'm not familiar with LDAP enough to suggest it, but it is there if you'd like to try... From what I've seen, and what we're doing, here's what I know is possible...

Apache has a mod_auth_mysql which will auth based on a MySQL database already... (http://sourceforge.net/projects/modauthmysql/)

That's trivial... They have a pam_mysql module as well that we use - it works... (http://sourceforge.net/projects/pam-mysql)...

Next on your list is inn, which I have no experience with. You'd most likely need to hack some form of parsing by e-mail address or IP (or password on a secured server) to verify/force identity...

ircd would be very easy to do... Shell account running a slightly modded "dircproxy" (http://www.dircproxy.net) would force identity based on a password, and would "proxy" the connection to the server transparantly.

Scp, if you're not using keys, could just use regular pam, with pam_mysql. Anyway, hope this helps.

LDAP may be a better solution, but I know for a fact this is possible (we're using these tools across apache, proftpd, scp, Courier-pop3/imap, and Exim for an MTA... we run a full ISP off these tools. Best of luck!

LDAP (3, Interesting)

photon317 (208409) | more than 11 years ago | (#4678878)


virtually everything you mentioned can be plugged up with LDAP one way or another.

Yes... (1, Funny)

Anonymous Coward | more than 11 years ago | (#4678961)

Someone has... They are called Microsoft and its called Passport authentication.... If you ask nice, you can probably get their specs. They are usually pretty good about sharing their code. ;-)

hmmm (0)

Anonymous Coward | more than 11 years ago | (#4678977)

Life will be much easier when I only have to compromise one password. Instead of one passwored per application.

Re:hmmm (1)

alphaque (51831) | more than 11 years ago | (#4694537)

It probably would, but then most users pick the same password for all their sign ons anyways, so it ain't much different, no ?

Another for the LDAP camp... (4, Interesting)

stefanlasiewski (63134) | more than 11 years ago | (#4678990)

My former organization (an NGO) attempted an single signon project for inn, rsync, & Apache 2 years ago. This was to be: a newsserver server, a webfrontend of the newsserver, web publishing, authoring tools, etc. We decide that LDAP was probably the best solution for a single signon.

Unfortunately back then, the software wasn't up to snuff, we had limited development experience to improve the existing tools, and we went bankrupt, and handed the project off to some other NGOs.

I've been recently laid off (Different company), and have been researching this project again. I'm amazed at the amount of progress that has been made since 2 years ago. It seems like LDAP is a good solution for single signon projects.

Apache 2.0 has added native support [apache.org] for LDAP, ldap; and there are several low-profile INN+LDAP projects out there (No large formal projects). I hear it's a good solution for remote-transfer users, like your 'scp' project.

Definately check out LDAP.

WebISO? (2)

quinto2000 (211211) | more than 11 years ago | (#4679001)

that's what it's for.

Liberty Alliance (2)

bill_mcgonigle (4333) | more than 11 years ago | (#4679201)

Kerberos+LDAP, as others have mentioned, is the best way to do it today, but if you'd like to hack on these projects to add single-signon capability, you might want to check out the Liberty Alliance [projectliberty.org] . This is an industry group founded to combat Microsoft's Passport power-play. Being backed by big business, it might be what actually becomes a viable market solution, even if LDAP+Kerberos is more elegant.

Lots of people will sing songs about you if you contribute Liberty Alliance support to all those projects.

What about... (0)

PinkX (607183) | more than 11 years ago | (#4679212)

M$N .net PASSPORT!!! Your universal authentication solution!!

Re:What about... (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#4680062)

Syd Barret? Is that you?

Don't forget about (3, Interesting)

biohazard99 (114288) | more than 11 years ago | (#4679301)

Horde [horde.org] . The only hole they have for your project is for IRC, but I'm bet it could be integrated from Jabber [jabber.org] readily.

Today, LDAP. Tomorrow, Liberty or Passport (4, Informative)

velkro (11) | more than 11 years ago | (#4679460)

Today's solution is to use LDAP.

I have, right now, the following systems integrated using LDAP for authentication:

Linux (anything that uses PAM - ssh, ftp, X)
AIX 5.1
Apache (mod_ldap)
IBM HTTP Server (mod_ibm_ldap)
Several internal apps (PHP, Perl, C/C++)
MS Active Directory & Exchange
Lotus SameTime, and Lotus QuickPlace
Nortel Contivity VPN systems

And probably one or two things I've forgotten. So it's probably simple enough to add in the bits (IRC mainly) for the rest.

Re:Today, LDAP. Tomorrow, Liberty or Passport (0)

Anonymous Coward | more than 11 years ago | (#4681984)

Please write HOWTOs.

Secstore / Factotum - plan9 (4, Interesting)

DrSkwid (118965) | more than 11 years ago | (#4679602)

The Fourth Edition of Plan 9 includes a substantially reworked security architecture, described in the USENIX Security 2002 conference paper [bell-labs.com] by Russ Cox, Eric Grosse, Rob Pike, Dave Presotto, and Sean Quinlan.

One particular aspect that other operating systems may wish to adopt is our single-signon solution. A process called factotum is used to hold credentials like passwords and public/private keypairs and perform cryptographic operations. Factotum allows clients to speak a variety of cryptographic protocols and therefore legacy application servers can participate in our single-signon system without change and without even knowing it exists.

The factotum has no direct permanent storage, but rather fetches credentials at startup from a secstore server on the network. To authenticate safely with the secstore, Password Authenticated Key-exchange is used; this implies that the user just has to remember and type one password and passive eavsdroppers or even active malicious intermediaries can not launch even a dictionary attack against the system. The credentials are encrypted for storage on secstore, so even an administrator there would have difficulty reading them.

To see the code for all this, download the Plan 9 distribution and look in /sys/src/cmd/auth, particularly subdirectories factotum and secstore. The libraries /sys/src/libmp and /sys/src/libsec may also interest you.

Queries to ehg@lucent.com.
Copyright © 2002 Lucent Technologies. All rights reserved.

PAM? (1)

Wonko the Sane (25252) | more than 11 years ago | (#4679715)

Unfortunately, each app has its own incompatible concept of a 'user identity.'
Is this not the exact problem PAM was designed to fix? Most applications today can be made PAM-aware, then you can any method you want to store security information (names passwords, priviladges, etc.)

from MIT (2)

QuietRiot (16908) | more than 11 years ago | (#4679808)

Kerberos.

Re:from MIT (2)

quinto2000 (211211) | more than 11 years ago | (#4679909)

and the WebISO group has a web front for Kerberos. The implementation our school uses is called Pubcookie. It's flexible and easy to tie in, because it acts as another HTTP authentication method.

PAM (2)

dago (25724) | more than 11 years ago | (#4680293)

That's it. [kernel.org]

Already integrated into solaris and linux.
Lots of apps supports it.
It also support many scheme of authentication, from simple passwd file to NT logon / SecureID / biometrics (ugh).

SingleSign On (3)

Zach Garner (74342) | more than 11 years ago | (#4680314)

Just a quick note:

Single Sign On refers to a system that allows a user to log in once and then have access to a number of subsystems. For instance, I'm an intern at UAB's Academic Computing department. Currently, we have our Bug management system (bugzilla), a CMS (phpWebSite) and a Task management system that all can be used by only logging in once. All applications except the simplest will need modifications to use Pubcookie.

The software we are using is called PubCookie and is developed by the University of Washington. Pubcookie is one of the tools being reviewed by the NSF's Middleware Initiative.

Single Sign On is a very popular and difficult problem right now, especially inter-realm SSO.

On the otherhand, if all you need is a unified username/password for your systems, you are in better luck. Many systems do support LDAP for authentication. Bugzilla has some beta LDAP support, PAM provides LDAP authentication for logging in, some CMS systems are starting to support it. Aside from that I am not sure what your options are.

PKIX (X.509 certificates) (2)

coyote-san (38515) | more than 11 years ago | (#4681413)

You can use PKIX (X.509 certificates) with much of this infrastructure - Apache + mod_ssl, innd, ldap, postgresql and mysql, etc. The main hassle is that the different applications don't (yet) have the same view of how certs should work... and many don't yet require checking full certificate chains because the non-crypto core developers don't want to drive away users without a full PKIX intrastructure.

Now if only ssh would use conventional certs....

Another vote for LDAP (2)

Linux_ho (205887) | more than 11 years ago | (#4681735)

Right now, at my company we are using OpenLDAP for these applications:

Sendmail >>> e-mail routing
maildap >>> E-mail group expansion
Cyrus >>> IMAP mail/news servers
SAMBA >>> Windows File sharing
Netatalk >>> Apple File sharing
FreeRADIUS >>> RAS and VPN authentication
BackupPC >>> End-user workstation backups
Apache >>> Intranet
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?