This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
To: modperl@apache.org
Date: Wed, 16 Jan 2002 14:14:20 -0500
Subject: Single login/sign-on for different web apps?
From: Vsevolod Ilyushchenko <simonf@cshl.edu>
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...
===
From: James G Smith <JGSmith@TAMU.Edu>
To: Vsevolod Ilyushchenko <simonf@cshl.edu>
Subject: Re: Single login/sign-on for different web apps?
Date: Wed, 16 Jan 2002 14:24:15 -0600
Vsevolod Ilyushchenko <simonf@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.
===
Date: Wed, 16 Jan 2002 12:31:03 -0800
From: Paul Lindner <lindner@inuus.com>
To: Vsevolod Ilyushchenko <simonf@cshl.edu>
Cc: modperl@apache.org
Subject: Re: Single login/sign-on for different web apps?
On Wed, Jan 16, 2002 at 02:14:20PM -0500, Vsevolod Ilyushchenko 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...
Here's one idea that worked for me in one application:
1) assume that all hosts share the same domain suffix:
www.foo.com
www.eng.foo.com
www.hr.foo.com
2) Define a common authentication cookie that is sent to *.foo.com.
This cookie could might contain the following information:
username, timestamp
Encrypt this info with a server-side key, and send it back to the
user from a login page.
Put all of this in a common perl module.
3) Perl-based applications can just use the module and the common key
to decrypt the contents of the cookie to find the authenticated
username. If the cookie is not present redirect to the central
authentication page, passing in the URL to return to after
authentication.
4) For non-perl applications consider writing a small handler that
takes a cookie and decodes it. Applications present the cookie to
the central auth server, which decodes and verifies it and returns
the encoded data back to the application.
===
Subject: Re: Single login/sign-on for different web apps?
From: "Jeffrey W. Baker" <jwbaker@acm.org>
To: JGSmith@TAMU.Edu
Cc: Vsevolod Ilyushchenko <simonf@cshl.edu>, modperl@apache.org
Date: 16 Jan 2002 12:53:17 -0800
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
===
Date: Wed, 16 Jan 2002 16:11:37 -0500
From: Aaron Johnson <solution@gina.net>
To: Vsevolod Ilyushchenko <simonf@cshl.edu>
Subject: Re: Single login/sign-on for different web apps?
Vsevolod Ilyushchenko 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...
We are working on/with a similar system right now.
We have an application that is written in Perl, but the people visiting
will most likely be signing on at a different point then our
applications sign in page. Our system was built to use its own internal
database for authentication and their app/login uses a different
method. The design requirements were that each side would have to do as
little possible to modify there application to work in our single sign
on solution.
We have the luxury of not being overly concerned with the security
aspect so please keep that in mind.
We setup a nightly sync program that verifies the data in the current
database vs. their login user information database.
Here is a less then detailed summary of how the system operates.
1) The user logs into the application through their application and they
are sent a cookie that contains the user name.
2) All links to our application are sent to a single page on their end
with the full url of the page they want as part of the query string.
3) They verify that the user is valid using whatever method they want.
4) The user is then redirected to a special page in our application that
expects the query string to contain two items, the user name and the
final URL to go to.
5) Our application verifies the HTTP_REFFERER and the query string
contains valid values.
6) Our application checks the database for a user matching the name sent
in. Then if the user already has a session if they do then they are
redirected to the correct page, otherwise it does a lookup in our system
to create a session for the user based on the incoming user name and
then redirects to the final URL.
Now a user can go between the two applications without concern since
they have a cookie for each domain.
If the user comes to our site the reverse of the above occurs.
This allowed us to plug into existing applications without a lot of
rework. It is also fairly language/platform independent.
As stated above I know there are some large security issues with this
approach.
Aaron Johnson
===
Date: Wed, 16 Jan 2002 21:06:18 +0000
From: Mark Maunder <mark@swiftcamel.com>
To: lindner@inuus.com
Subject: Re: Single login/sign-on for different web apps?
> Here's one idea that worked for me in one application:
>
> 1) assume that all hosts share the same domain suffix:
>
> www.foo.com
> www.eng.foo.com
> www.hr.foo.com
>
> 2) Define a common authentication cookie that is sent to *.foo.com.
> This cookie could might contain the following information:
>
> username, timestamp
That's cool, but any ideas on how to do this with different domain names i.e.
foo.com, bar.com, baz.com and boo.com? You can't create cookies for the .com
domain, so there's no way to hand out auth cookies from foo.com (when the user
logs into foo.com) and have the browser send them to bar.com too. Also foo.com
can't hand out cookies for bar.com, so you can't implement a single sign on
using cookies for multiple domain names from the same host.
The only way I could come up with, was to have the browser redirected to every
domain name with an encrypted uri variable to prove it is signed on which causes
each host included in the single sign on to assign an auth cookie to the
browser.
So the browser is logged into foo.com, bar.com baz.com and boo.com by logging
into foo.com which assigns a cookie and redirects to bar.com which assigns a
cookie and redirects it to baz.com which assigns a cookie and redirects it to
boo.com which assigns a cookie and redirects it back to foo.com. It has now
collected all cookies required for signon to all domain names and is logged into
all of them.
So you end up with something like hotmail.com where you are redirected to like 5
different sites when you login before you get to your inbox. *yuck*. Anyone got
a better idea for this?
===
From: Daniel Little <danl@metrex.net>
To: "'Mark Maunder'" <mark@swiftcamel.com>
Cc: modperl@apache.org
Subject: RE: Single login/sign-on for different web apps?
Date: Wed, 16 Jan 2002 15:32:43 -0600
> From: Mark Maunder [mailto:mark@swiftcamel.com]
>
> > Here's one idea that worked for me in one application:
> >
> > 1) assume that all hosts share the same domain suffix:
> >
> > www.foo.com
> > www.eng.foo.com
> > www.hr.foo.com
> >
> > 2) Define a common authentication cookie that is sent to *.foo.com.
> > This cookie could might contain the following information:
> >
> > username, timestamp
>
> The only way I could come up with, was to have the browser
> redirected to every domain name with an encrypted uri variable
> to prove it is signed on which causes each host included in
> the single sign on to assign an auth cookie to the browser.
>
> So the browser is logged into foo.com, bar.com baz.com and
> boo.com by logging into foo.com which assigns a cookie and
> redirects to bar.com which assigns a cookie and redirects
> it to baz.com which assigns a cookie and redirects it to
> boo.com which assigns a cookie and redirects it back to
> foo.com. It has now collected all cookies required for
> signon to all domain names and is logged into all of them.
An alternative to this scheme - and depending on how much control you have
over the applications / servers at each end - is to do this in a delayed
fashion. The only time you really need to get authenticated at each server
is when the browser is sent off to the new site. Instead of redirecting the
browser to the new site directly, it sends it to a script on the server that
they are currently connected to (and therefore already authenticated with)
which requests a 'transition' token of some kind from the authentication
server. The transition token then is used to transfer them to the requested
server, which based on the token, does a lookup on the authentication server
to find out if its a valid transition token, and if so, generates a new
cookie for them (if necessary) and logs them into the site.
There are a few security risks I can see with this mechanism but they can be
reduced somewhat by ensuring that the life of the token is very short. When
someone is redirected to the new site and the authentication server
generates the transition token, so long as the token has a TTL of only a few
seconds, you reduce the risk of someone trying to send the token on to a
third party to automatically log you into the site.
Whichever way I see it right now, though, there aren't a lot of good secure
alternatives if you don't have total control over all the applications on
all of the sites. I'd love to see a better solution for this though.
===
Date: Wed, 16 Jan 2002 17:38:12 -0500
From: Vsevolod Ilyushchenko <simonf@cshl.edu>
To: modperl@apache.org
Subject: Re: Single login/sign-on for different web apps?
> An alternative to this scheme - and depending on how much control you have
> over the applications / servers at each end - is to do this in a delayed
> fashion. The only time you really need to get authenticated at each server
> is when the browser is sent off to the new site. Instead of redirecting the
> browser to the new site directly, it sends it to a script on the server that
> they are currently connected to (and therefore already authenticated with)
> which requests a 'transition' token of some kind from the authentication
> server. The transition token then is used to transfer them to the requested
> server, which based on the token, does a lookup on the authentication server
> to find out if its a valid transition token, and if so, generates a new
> cookie for them (if necessary) and logs them into the site.
Yes, but I still should be able to propely handle people who go to any of
the protected sites first thing in the morning. I don't think I can get
away with only exit-point authentication that you propose. If the
entrance-point authentication works well, there should be no need for this
additional level. (Please correct me if I am wrong. :)
Simon
===
Date: Thu, 17 Jan 2002 12:16:11 +1300
From: Steve Piner <stevep@marketview.co.nz>
To: modperl@apache.org
Subject: Re: Single login/sign-on for different web apps?
Vsevolod Ilyushchenko wrote:
> Yes, but I still should be able to propely handle people who go to any of
> the protected sites first thing in the morning. I don't think I can get
> away with only exit-point authentication that you propose. If the
> entrance-point authentication works well, there should be no need for this
> additional level. (Please correct me if I am wrong. :)
Do cookies get set if returned via an image?
If so, once the user has logged in, you could return a page with
invisible images on it, where each image is from each site that the user
needs to be authenticated to.
Each image is unimportant. The important bit is that an authentication
cookie is set for each domain the image is returned from.
This leaves one tricky point as far as I can see: you need to securely
identify which image request comes from each user. The obvious/easy way
would be to put some sort of unique identifier in the path or query
string, but this may not be secure enough for your purposes.
Oh yeah, it'd break if they didn't have images on. :-(
===
Date: Wed, 16 Jan 2002 18:56:37 -0500
From: Vsevolod Ilyushchenko <simonf@cshl.edu>
To: lindner@inuus.com
Subject: Re: Single login/sign-on for different web apps?
>
> 3) Perl-based applications can just use the module and the common key
> to decrypt the contents of the cookie to find the authenticated
> username. If the cookie is not present redirect to the central
> authentication page, passing in the URL to return to after
> authentication.
Hmmm... Can I do it securely without using Kerberos? I think so. Looks like
if I use https instead of http, people won't be able to steal my (encoded)
session information as it is transmitted. And I can also add the IP address
to the cookie information.
But the cookies file might be readable by other people! If they can steal
that file and change the IP address of another machine to yours, they can
pretend they are you!
I wonder if there is a way out of this...
===
Date: Wed, 16 Jan 2002 15:58:42 -0800
From: Paul Lindner <lindner@inuus.com>
To: Vsevolod Ilyushchenko <simonf@cshl.edu>
Cc: lindner@inuus.com, modperl@apache.org
Subject: Re: Single login/sign-on for different web apps?
On Wed, Jan 16, 2002 at 06:56:37PM -0500, Vsevolod Ilyushchenko wrote:
> >
> > 3) Perl-based applications can just use the module and the common key
> > to decrypt the contents of the cookie to find the authenticated
> > username. If the cookie is not present redirect to the central
> > authentication page, passing in the URL to return to after
> > authentication.
>
> Hmmm... Can I do it securely without using Kerberos? I think so. Looks like
> if I use https instead of http, people won't be able to steal my (encoded)
> session information as it is transmitted. And I can also add the IP address
> to the cookie information.
>
> But the cookies file might be readable by other people! If they can steal
> that file and change the IP address of another machine to yours, they can
> pretend they are you!
> I wonder if there is a way out of this...
Yes, you use the timestamp. Just reauthenticate the user when they
try to do 'sensitive' activities.
For example you might allow someone to view their bank balance if they
typed their password within the last 2 hours. Transferring money
might require a valid password within the last 10 minutes..
Of course, the best authentication system for banking I've seen is
from UBS. They send you a scratchlist of around 100 numbers. Every
time you login you use one of the numbers and cross it off. Very
slick.
===
Date: Thu, 17 Jan 2002 01:23:04 +0000
From: Mark Maunder <mark@swiftcamel.com>
To: Daniel Little <danl@metrex.net>
Subject: Re: Single login/sign-on for different web apps?
Daniel Little wrote:
> > From: Mark Maunder [mailto:mark@swiftcamel.com]
> >
> > > Here's one idea that worked for me in one application:
> > >
> > > 1) assume that all hosts share the same domain suffix:
> > >
> > > www.foo.com
> > > www.eng.foo.com
> > > www.hr.foo.com
> > >
> > > 2) Define a common authentication cookie that is sent to *.foo.com.
> > > This cookie could might contain the following information:
> > >
> > > username, timestamp
> >
> > The only way I could come up with, was to have the browser
> > redirected to every domain name with an encrypted uri variable
> > to prove it is signed on which causes each host included in
> > the single sign on to assign an auth cookie to the browser.
> >
> > So the browser is logged into foo.com, bar.com baz.com and
> > boo.com by logging into foo.com which assigns a cookie and
> > redirects to bar.com which assigns a cookie and redirects
> > it to baz.com which assigns a cookie and redirects it to
> > boo.com which assigns a cookie and redirects it back to
> > foo.com. It has now collected all cookies required for
> > signon to all domain names and is logged into all of them.
>
> An alternative to this scheme - and depending on how much control you have
> over the applications / servers at each end - is to do this in a delayed
> fashion. The only time you really need to get authenticated at each server
> is when the browser is sent off to the new site. Instead of redirecting the
> browser to the new site directly, it sends it to a script on the server that
> they are currently connected to (and therefore already authenticated with)
> which requests a 'transition' token of some kind from the authentication
> server. The transition token then is used to transfer them to the requested
> server, which based on the token, does a lookup on the authentication server
> to find out if its a valid transition token, and if so, generates a new
> cookie for them (if necessary) and logs them into the site.
>
This assumes they dont just type in the url of the other site they want to visit
manually. It limits the user to visiting sites via links on sites they are
currently logged on to.
===
Date: Wed, 16 Jan 2002 18:58:27 -0800
From: Medi Montaseri <medi@cybershell.com>
To: Aaron Johnson <solution@gina.net>
Subject: Re: Single login/sign-on for different web apps?
I think Netegrity single sing-on system modifies the HTTP
server (possible with mod_perl) to overload or override its
native authoentication and instead contact a Host, Database
or LDAP to get the yes or no along with expiration
data.... it then sends its finding to the CGI by sending
additonal HTTP Header info. A CGI program can then go from
there...
I might not have this 100%, but perhaps we can learn from
those commercial products.
Someone suggested using LDAP and RDBMS, my question is why
both, why not just RDBMS.
===
Date: Wed, 16 Jan 2002 19:37:21 -0800
From: Medi Montaseri <medi@cybershell.com>
To: Ed Grimm <ed@tgape.org>
Subject: Re: Single login/sign-on for different web apps?
Ed Grimm wrote:
> On Wed, 16 Jan 2002, Medi Montaseri wrote:
>
> > I think Netegrity single sing-on system modifies the HTTP server
> > (possible with mod_perl) to overload or override its native
> > authoentication and instead contact a Host, Database or LDAP to get
> > the yes or no along with expiration data.... it then sends its finding
> > to the CGI by sending additonal HTTP Header info. A CGI program can
> > then go from there...
>
> Something like this. Basically, it has modules, plugins, or access
> instructions, as appropriate, for various web servers, to configure them
> to use it. I know it gives an LDAP interface, and I'm assuming it gives
> an LDAPS interface; I'm not sure what others it may present.
>
> > I might not have this 100%, but perhaps we can learn from those
> > commercial products.
> >
> > Someone suggested using LDAP and RDBMS, my question is why both, why
> > not just RDBMS.
>
> Why not just LDAP? As someone working on rolling out a single sign-on
> solution with LDAPS, I really want to know... (We're planning on
> getting Netegrity for its distributed administration stuff; at that
> time, we'll start using its web server configuration stuff for any new
> web servers. Until that time, we're rolling out LDAPS, and we're not
> currently planning on converting systems we roll out in the interm to
> Netegrity.)
>
> Incidentally, we're being a bunch of lazy bums, compared to the rest of
> y'all. We're considering single sign-on to mean they only need to keep
> track of one userid and password (unless they need to access classified
> or otherwise restricted stuff.) If they go to different sites and have
> to log on again, we don't currently care. (Basically, we have too many
> sites created by too many groups. We'll share the same login between
> servers run by the same group, but beyond that, security concerns
> outweigh user convinience.)
>
> Ed
I wonder if one could change the HTTP Server's behavior to process a
distributed version of "AuthUserFile" and "AuthGroupFile".
That instead of
AuthUserFile "/some/secure/directory/.htpasswd
One would say
AuthUserFile "http://xyz.com/some/directory/htpasswd"
Then write a GUI (web) inteface to this password and group file and
you have distributed authentication system.
===
Date: Thu, 17 Jan 2002 12:29:29 +0800
To: lindner@inuus.com, Vsevolod Ilyushchenko <simonf@cshl.edu>
From: Gunther Birznieks <gunther@extropia.com>
Subject: Re: Single login/sign-on for different web apps?
Cc: lindner@inuus.com, modperl@apache.org
>
>Of course, the best authentication system for banking I've seen is
>from UBS. They send you a scratchlist of around 100 numbers. Every
>time you login you use one of the numbers and cross it off. Very
>slick.
Does that really work in practice? That sounds really annoying. Is this for
business banking or for retail? How do they get the next 100 numbers to the
user? Do they mail it out when they've used 90?
It sounds like it would be less annoying to use certificates and some
plug-in token there is going to be that much extra work to deal with a
password sheet.
===
Date: Thu, 17 Jan 2002 00:26:22 -0500
From: Aaron Johnson <solution@gina.net>
To: Gunther Birznieks <gunther@extropia.com>
Subject: Re: Single login/sign-on for different web apps?
Gunther Birznieks wrote:
>
> >
> >Of course, the best authentication system for banking I've seen is
> >from UBS. They send you a scratchlist of around 100 numbers. Every
> >time you login you use one of the numbers and cross it off. Very
> >slick.
>
> Does that really work in practice? That sounds really annoying. Is this for
> business banking or for retail? How do they get the next 100 numbers to the
> user? Do they mail it out when they've used 90?
>
> It sounds like it would be less annoying to use certificates and some
> plug-in token there is going to be that much extra work to deal with a
> password sheet.
I hadn't really taken a look at personal certificates until this thread
came up. It looks like thawte is offering personal certificates at no
charge.
http://www.thawte.com/getinfo/products/personal/contents.html
This would make it a more likely method since lots of site
traffic wouldn't want to pay and people tyring out the service wouldn't
be forced to pay just to login.
When you say plug-in token are you talking about a browser plug-in?
Aaron Johnson
More Resources for PKI, CA, etc.
http://ospkibook.sourceforge.net/docs/OSPKI-2.4.6/OSPKI/impl-mozilla.htm
http://www.openca.org/
http://www.pki-page.org/
===
Date: Wed, 16 Jan 2002 22:57:55 -0800 (PST)
From: Andrew Ho <andrew@tellme.com>
To: mod_perl List <modperl@apache.org>
Subject: Re: Single login/sign-on for different web apps?
Hello,
PL>Of course, the best authentication system for banking I've seen is
PL>from UBS. They send you a scratchlist of around 100 numbers. Every
PL>time you login you use one of the numbers and cross it off. Very
PL>slick.
GB>Does that really work in practice? That sounds really annoying. Is this
GB>for business banking or for retail? How do they get the next 100 numbers
GB>to the user? Do they mail it out when they've used 90?
The ACE SecurID system (I think they're owned by RSA now) refines this
process well. You have a hardy little credit-card sized (or key fob sized,
and I'm sure they have other form factors) object. It has a little LCD
screen and every 30 seconds the 4- to 6-digit number on it changes. When
you log into the server, you give it your ID, a password, AND the number
currently on your SecurID card or key fob.
The key fob is nice. It's hardy and lasts a long time. I have one from
Motorola from my stint there many years ago. You could probably toss it on
the sidewalk from my third-story balcony and it'd be okay, plus it's
small and easy to read.
This is inferior to a true zero-knowledge challenge-response system which
would require a little calculator, but it's far more secure than a
password and far easier to use than paper and pencil.
Here's the RSA SecurID URL:
http://www.rsasecurity.com/products/securid/
Here's a picture of some of the hardware tokens:
http://www.rsasecurity.com/products/securid/hardware_token.html
I guess they DO have a challenge-response calculator. Neat.
===
Date: Thu, 17 Jan 2002 08:52:36 +0000 (GMT)
From: Mark Fowler <mark@twoshortplanks.com>
To: <modperl@apache.org>
Subject: Re: Single login/sign-on for different web apps?
On Wed, 16 Jan 2002, Mark Maunder wrote:
> The only way I could come up with, was to have the browser redirected
> to every domain name with an encrypted uri variable to prove it is
> signed on which causes each host included in the single sign on to
> assign an auth cookie to the browser.
Instead of redirecting the entire page you could just include images
(the typical 1x1 pixel) from each server on the "You've been logged on"
page and have each of them set a cookie for that domain name.
For this to work with modern browsers (i.e. IE6 and properly configured
mozillas) you'll need to include a compact policy in your P3P header[1],
otherwise the browser will consider this an unauthorised attempt to serve
a "third party image" and block the cookie.
Later.
Mark.
[1] See http://www.w3c.org/p3p/,
http://2shortplanks.com/temp/P3P-ToCP-0.02.tar.gz for more information
===
Date: Thu, 17 Jan 2002 11:58:07 +0100
From: "C.Hauser - IT assistance GmbH" <c.hauser@itassistance.ch>
To: Gunther Birznieks <gunther@extropia.com>
Subject: Re[2]: Single login/sign-on for different web apps?
>>Of course, the best authentication system for banking I've seen is
>>from UBS. They send you a scratchlist of around 100 numbers. Every
>>time you login you use one of the numbers and cross it off. Very
>>slick.
>
> Does that really work in practice? That sounds really annoying. Is this for
> business banking or for retail? How do they get the next 100 numbers to the
> user? Do they mail it out when they've used 90?
It works, as I'm a customer of UBS. They do it for everybody, business and
private. They send the the scratchlist by post, even, registered.
When you reach the 80th number, a new list will be automatically sent.
===
Date: Thu, 17 Jan 2002 12:27:32 +0100
From: Dominique Quatravaux <dom@idealx.com>
To: modperl@apache.org
Subject: Re: Single login/sign-on for different web apps?
> I hadn't really taken a look at personal certificates until this thread
> came up. It looks like thawte is offering personal certificates at no
> charge.
>
> http://www.thawte.com/getinfo/products/personal/contents.html
Yep, and the society I work in develops a GPLed PKI, which is a
Perl+PHP+LDAP app for rolling your own certificates (both user and
server):
http://idx-pki.idealx.com/
Certificates are indeed a straightforward way of getting SSO - but
you have to carry your certificate with you whenever you change
workstations. Here are reasonable solutions (trading security for
convenience):
* most secure: use USB crypto tokens (slow and extra per-user price,
but will safeguard the private key and destroy it upon attack);
* very secure: use dedicated workstations, one per user
(impractical), or laptops (expensive but may be amortized with
other needs);
* not so secure (equivalent of password SSO): carry the key on a
floppy, and keep it password-encrypted at all times.
On the server side, you have to get your Apache to grok certificates
(easy with recent versions of openssl), and the authentication info
then gets passed down to PHP and Perl scripts as environment variables
("OK, this guy is called CN=John Doe, OU=sales, O=yourcompany - trust
me on this"). You have to patch your apps, sure, but all the burden of
binding a bunch of crypto bits to a name is removed from you in a
highly secure fashion.
===
Date: Thu, 17 Jan 2002 17:06:55 -0600
From: Jim Smith <jgsmith@moya.tamu.edu>
To: "Jeffrey W. Baker" <jwbaker@acm.org>
Cc: JGSmith@TAMU.Edu, Vsevolod Ilyushchenko <simonf@cshl.edu>,
Subject: Re: Single login/sign-on for different web apps?
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.
===
Date: Thu, 17 Jan 2002 18:48:31 -0500
To: Mark Maunder <mark@swiftcamel.com>, lindner@inuus.com
From: Robert Landrum <rlandrum@capitoladvantage.com>
Subject: Re: Single login/sign-on for different web apps?
Cc: Vsevolod Ilyushchenko <simonf@cshl.edu>, modperl@apache.org
At 9:06 PM +0000 1/16/02, Mark Maunder wrote:
>That's cool, but any ideas on how to do this with different domain names i.e.
>foo.com, bar.com, baz.com and boo.com? You can't create cookies for the .com
>domain, so there's no way to hand out auth cookies from foo.com (when the user
>logs into foo.com) and have the browser send them to bar.com too. Also foo.com
>can't hand out cookies for bar.com, so you can't implement a single sign on
>using cookies for multiple domain names from the same host.
>
>The only way I could come up with, was to have the browser redirected to every
>domain name with an encrypted uri variable to prove it is signed on
>which causes
>each host included in the single sign on to assign an auth cookie to the
>browser.
>So the browser is logged into foo.com, bar.com baz.com and boo.com by logging
>into foo.com which assigns a cookie and redirects to bar.com which assigns a
>cookie and redirects it to baz.com which assigns a cookie and redirects it to
>boo.com which assigns a cookie and redirects it back to foo.com. It has now
>collected all cookies required for signon to all domain names and is
>logged into
>all of them.
That's not terribly efficient for the user. If I were to do this,
I'd probably put some "You are now logged in" page that loads images
from foo.com, bar.com, baz.com, and boo.com (transparent single pixel
gifs would work).
Now the user is logged in to all those servers (provided that the
gifs returned were returned with Set-Cookie headers).
The same thing can be done with authentication. Most browsers allow
you to write urls as
http://user:pass@host.com/images/spacer.gif
It's not pretty, and not super secure, but it does work.
===
To: Medi Montaseri <medi@cybershell.com>
From: Ed Grimm <ed@tgape.org>
Subject: Re: Single login/sign-on for different web apps?
Date: Wed, 16 Jan 2002 20:53:45 -0500 (EST)
On Wed, 16 Jan 2002, Medi Montaseri wrote:
> Ed Grimm wrote:
> > On Wed, 16 Jan 2002, Medi Montaseri wrote:
> > > Aaron Johnson wrote:
> > >> Vsevolod Ilyushchenko wrote:
> > >>> 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...
> > >
> > >> We are working on/with a similar system right now.
> > >>
> > >> We have an application that is written in Perl, but the people
> > >> visiting will most likely be signing on at a different point then our
> > >> applications sign in page. Our system was built to use its own
> > >> internal database for authentication and their app/login uses a
> > >> different method. The design requirements were that each side would
> > >> have to do as little possible to modify there application to work in
> > >> our single sign on solution.
> > >>
> > >> We have the luxury of not being overly concerned with the security
> > >> aspect so please keep that in mind.
> > >>
> > >> We setup a nightly sync program that verifies the data in the current
> > >> database vs. their login user information database.
> > >>
> > >> Here is a less then detailed summary of how the system operates.
> > >>
> > >> 1) The user logs into the application through their application and
> > >> they are sent a cookie that contains the user name.
> > >>
> > >> 2) All links to our application are sent to a single page on their
> > >> end with the full url of the page they want as part of the query
> > >> string.
> > >>
> > >> 3) They verify that the user is valid using whatever method they
> > >> want.
> > >>
> > >> 4) The user is then redirected to a special page in our application
> > >> that expects the query string to contain two items, the user name and
> > >> the final URL to go to.
> > >>
> > >> 5) Our application verifies the HTTP_REFFERER and the query string
> > >> contains valid values.
> > >>
> > >> 6) Our application checks the database for a user matching the name
> > >> sent in. Then if the user already has a session if they do then they
> > >> are redirected to the correct page, otherwise it does a lookup in our
> > >> system to create a session for the user based on the incoming user
> > >> name and then redirects to the final URL.
> > >>
> > >> Now a user can go between the two applications without concern since
> > >> they have a cookie for each domain.
> > >>
> > >> If the user comes to our site the reverse of the above occurs.
> > >>
> > >> This allowed us to plug into existing applications without a lot of
> > >> rework. It is also fairly language/platform independent.
> > >>
> > >> As stated above I know there are some large security issues with this
> > >> approach.
> > >>
> > >> Aaron Johnson
> > >>
> > > I think Netegrity single sing-on system modifies the HTTP server
> > > (possible with mod_perl) to overload or override its native
> > > authoentication and instead contact a Host, Database or LDAP to get
> > > the yes or no along with expiration data.... it then sends its finding
> > > to the CGI by sending additonal HTTP Header info. A CGI program can
> > > then go from there...
> >
> > Something like this. Basically, it has modules, plugins, or access
> > instructions, as appropriate, for various web servers, to configure them
> > to use it. I know it gives an LDAP interface, and I'm assuming it gives
> > an LDAPS interface; I'm not sure what others it may present.
> >
> > > I might not have this 100%, but perhaps we can learn from those
> > > commercial products.
> > >
> > > Someone suggested using LDAP and RDBMS, my question is why both, why
> > > not just RDBMS.
> >
> > Why not just LDAP? As someone working on rolling out a single sign-on
> > solution with LDAPS, I really want to know... (We're planning on
> > getting Netegrity for its distributed administration stuff; at that
> > time, we'll start using its web server configuration stuff for any new
> > web servers. Until that time, we're rolling out LDAPS, and we're not
> > currently planning on converting systems we roll out in the interm to
> > Netegrity.)
> >
> > Incidentally, we're being a bunch of lazy bums, compared to the rest of
> > y'all. We're considering single sign-on to mean they only need to keep
> > track of one userid and password (unless they need to access classified
> > or otherwise restricted stuff.) If they go to different sites and have
> > to log on again, we don't currently care. (Basically, we have too many
> > sites created by too many groups. We'll share the same login between
> > servers run by the same group, but beyond that, security concerns
> > outweigh user convinience.)
> >
> > Ed
> >
> I wonder if one could change the HTTP Server's behavior to process a
> distributed version of "AuthUserFile" and "AuthGroupFile".
>
> That instead of
>
> AuthUserFile "/some/secure/directory/.htpasswd
>
> One would say
>
> AuthUserFile "http://xyz.com/some/directory/htpasswd"
>
> Then write a GUI (web) inteface to this password and group file and
> you have distributed authentication system.
>
No. There are very important reasons why Apache by default puts an ACL
restricting .ht* from being viewable. (Basically, the password encryption
used in said file is moderately easily cracked via brute force.)
One could use a file distributed using rsync(1) or some such (preferably
with RSYNC_RSH=ssh). However, that's still a bit on the unsecure side,
unless you really do trust everyone who is running one of these web
servers.
Ed
===
To: Medi Montaseri <medi@cybershell.com>
From: Ed Grimm <ed@tgape.org>
Subject: Re: Single login/sign-on for different web apps?
Date: Wed, 16 Jan 2002 20:18:23 -0500 (EST)
On Wed, 16 Jan 2002, Medi Montaseri wrote:
> I think Netegrity single sing-on system modifies the HTTP server
> (possible with mod_perl) to overload or override its native
> authoentication and instead contact a Host, Database or LDAP to get
> the yes or no along with expiration data.... it then sends its finding
> to the CGI by sending additonal HTTP Header info. A CGI program can
> then go from there...
Something like this. Basically, it has modules, plugins, or access
instructions, as appropriate, for various web servers, to configure them
to use it. I know it gives an LDAP interface, and I'm assuming it gives
an LDAPS interface; I'm not sure what others it may present.
> I might not have this 100%, but perhaps we can learn from those
> commercial products.
>
> Someone suggested using LDAP and RDBMS, my question is why both, why
> not just RDBMS.
Why not just LDAP? As someone working on rolling out a single sign-on
solution with LDAPS, I really want to know... (We're planning on
getting Netegrity for its distributed administration stuff; at that
time, we'll start using its web server configuration stuff for any new
web servers. Until that time, we're rolling out LDAPS, and we're not
currently planning on converting systems we roll out in the interm to
Netegrity.)
Incidentally, we're being a bunch of lazy bums, compared to the rest of
y'all. We're considering single sign-on to mean they only need to keep
track of one userid and password (unless they need to access classified
or otherwise restricted stuff.) If they go to different sites and have
to log on again, we don't currently care. (Basically, we have too many
sites created by too many groups. We'll share the same login between
servers run by the same group, but beyond that, security concerns
outweigh user convinience.)
===
To: Gunther Birznieks <gunther@extropia.com>
From: Ed Grimm <ed@tgape.org>
Subject: Re: Single login/sign-on for different web apps?
Date: Wed, 16 Jan 2002 22:51:19 -0500 (EST)
On Thu, 17 Jan 2002, Gunther Birznieks wrote:
> >Of course, the best authentication system for banking I've seen is
> >from UBS. They send you a scratchlist of around 100 numbers. Every
> >time you login you use one of the numbers and cross it off. Very
> >slick.
>
> Does that really work in practice? That sounds really annoying. Is this for
> business banking or for retail? How do they get the next 100 numbers to the
> user? Do they mail it out when they've used 90?
>
> It sounds like it would be less annoying to use certificates and some
> plug-in token there is going to be that much extra work to deal with a
> password sheet.
Alternately, for a high-tech approach, RSA makes a nice product called a
SecurID token (Well, one of mine says Security Dynamics on the back, but
the new ones definitely say RSA). Actually, they make two, one nice,
one not nice. The nice one has a keypad where you enter in a pin, press
a button, and it generates a temporary id based on its serial number,
your pin, and the current time interval; the time interval changes every
minute or two. The not nice one has no keypad; it works like the other
would if you didn't enter a pin.
I know of several companies that use these; they tend to work fairly
well. (I had one break on me, but I gave it a lot of abuse first; it
lasted almost half of its battery span in spite of not being taken care
of.)
Ed
===