Re: Single login/sign-on for different web apps?

[James G Smith <JG...@TAMU.Edu>]

Vsevolod Ilyushchenko <si...@cshl.edu> wrote:
>Hi,
>
>Have you ever ran into the problem of putting up many separate web apps on
>several machines in your company/university/whatever that are written from
>scratch or downloaded frow the Web and each of which has its own user
>database? What would you think is a good way to make the system seem more
>cohesive for the users?
>
>It occurs to me that 1) for the single login they all should use the same
>user database (obviously :), and 2) for the single sign-on there must be a
>way of storing the session information. That is, once I login in the
>morning to the first app, I get a cookie, a ticket or something similar,
>and then, as I go from app to app, I will not have to re-enter my
>credentials because they are supplied by a cookie. Apache::Session sounds
>like the right tool for the job. (Did I hear "Kerberos"? :)
>
>Has anyone had experince with this kind of app integration? The downside I
>see is that once I settle on a particular scheme to do it, I will have to
>build this scheme into every app that was not written internally. But
>that's the life in the before-standards age, I guess... 

I did some work towards supporting single-sign-on a couple years ago:
Authen::Ticket.  We haven't actually done anything with it since
though.

We have Kerberos here, with management via a web interface (currently
being rewritten from PHP to Perl).  The things to watch out for with
Kerberos:

  PHP does not directly support Kerberos 5, if there is a PHP
  extension, I haven't seen it.  Perl has a module for it.  Some
  applications are written in PHP, some in Perl, and some don't come
  with source.

  Any service that uses Kerberos for authentication MUST only allow
  login via a secure connection -- HTTP, IMAP, POP, shell, etc.
  Otherwise, the security of Kerberos is defeated.

We hold account information other than passwords in LDAP, using
OpenLDAP.  OpenLDAP can use Kerberos, so applications that can't use
Kerberos directly but can support a secure LDAP connection can use
that.  PHP supports secure LDAP (iirc) and secure IMAP, at least if
the right crypto libs are included.

Sessions are held in MySQL since that was the quickest for us to get
up and running.  It supports replication, though I'm waiting for 4.0
to be stable so I can test it -- it's supposed to have better
replication support.  Sessions are not shared across apps.

There is no standard method of doing single sign-on.  When I
submitted a draft for such a beast to be put in HTTP, the main
concern was opening up more privacy holes than cookies currently do.

With LDAP and Kerberos, Unix systems using PAM can/should be able to
use it to replace the password files or NIS.
-- 
James Smith <JG...@TAMU.Edu>, 979-862-3725
Texas A&M CIS Operating Systems Group, Unix

Re: Single login/sign-on for different web apps?

[Jim Smith <jg...@moya.tamu.edu>]

On Wed, Jan 16, 2002 at 12:53:17PM -0800, Jeffrey W. Baker wrote:
> On Wed, 2002-01-16 at 12:24, James G Smith wrote:
> 
> > There is no standard method of doing single sign-on.  When I
> > submitted a draft for such a beast to be put in HTTP, the main
> > concern was opening up more privacy holes than cookies currently do.
> 
> You don't need to add anything to the protocol because client
> certificates already implement a useful single sign-on system.

This is true if client certificates are used -- this wasn't a
realistic expectation at the time, nor will it be here for a few more
years, most likely.

--jim

Re: Single login/sign-on for different web apps?

["Jeffrey W. Baker" <jw...@acm.org>]

On Wed, 2002-01-16 at 12:24, James G Smith wrote:

> There is no standard method of doing single sign-on.  When I
> submitted a draft for such a beast to be put in HTTP, the main
> concern was opening up more privacy holes than cookies currently do.

You don't need to add anything to the protocol because client
certificates already implement a useful single sign-on system.

-jwb