Skip site navigation (1) Skip section navigation (2)

Re: Design Considerations for New Authentication Methods

From: "Magnus Hagander" <mha(at)sollentuna(dot)net>
To: "Richard Troy" <rtroy(at)ScienceTools(dot)com>
Cc: "Stephen Frost" <sfrost(at)snowman(dot)net>,"Martijn van Oosterhout" <kleptog(at)svana(dot)org>,"Henry B(dot) Hotz" <hotz(at)jpl(dot)nasa(dot)gov>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Design Considerations for New Authentication Methods
Date: 2006-11-02 21:48:29
Message-ID: 6BCB9D8A16AC4241919521715F4D8BCEA0FCEC@algol.sollentuna.se (view raw or flat)
Thread:
Lists: pgsql-hackers
> Would signed certificates be preferred? Well, sure, they're 
> nice. I don't object, and in fact welcome some improvements 
> here. For example, I'd love the choice of taking an 
> individual user's certificate and authenticating completely 
> based upon that. However, while this _seems_ to simplify 
> things, it really just trades off with the added cost of 
> managing those certs - username/password is slam-dunk simple 
> and has the advantage that users can share one authentication.
> 
> Unless I've really overlooked something basic, there's 
> nothing lacking in the existing scheme...

From my POV, yes, you are missing sometihng very basic - single signon.
This is what Kerberos gives me. No need for the user to type in his
password, becaus ehe is *already* logged in and authenticated by a
trusted KDC in the realm.

The same could apply to SSL cert based authentication, for users
connecting from machines outside of my realm. Once you have "unlocked"
the certificate, you can authenticate any number of times to any number
of services that will accept this certificate *without* having to
re-enter your password.

This is both a convenience for the user, and a requirement if you use
OTPs.

//Magnus

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2006-11-02 21:50:31
Subject: Re: [PATCHES] WAL logging freezing
Previous:From: Henry B. HotzDate: 2006-11-02 21:10:14
Subject: Re: Design Considerations for New Authentication Methods

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group