Thread: Authenticating from a web service call

Hello,
We are looking at implementing a web service that basically makes calls to the database.

I have been thinking about ways to secure the web service based on the database.

I initially thought about just connecting to the database as the user with parameters passed through the web service - however I don't know how to do that other than clear text passwords.

So, is it possible for clients to encrypt their password and pass that through the web service to the database? I was looking at the way postgres stores the users passwords but first of all I'm not sure if that is something the client could do. Then, if they could, how to go about connecting as a system user and verifying that the userid and password provided by the client are correct.

I could just provide another table with an encrypted password using a specified encryption process that the client can replicate and provide through the web service.

Hopefully this makes sense :)

Bryan.

On 16/03/2012 18:39, Bryan Montgomery wrote:
> Hello,
> We are looking at implementing a web service that basically makes calls
> to the database.
>
> I have been thinking about ways to secure the web service based on the
> database.
>
> I initially thought about just connecting to the database as the user
> with parameters passed through the web service - however I don't know
> how to do that other than clear text passwords.

Postgres supports connections over SSL - will this do the job?

http://www.postgresql.org/docs/9.1/static/ssl-tcp.html

Ray.


--
Raymond O'Donnell :: Galway :: Ireland
rod@iol.ie

Interesting idea. However, I think this is ssl between the client and database. Given the client would be the server hosting the web service I don't think this would work for the web service client.

Actually, through some experimentation, googling and looking at a postgres book, I found out how to encrypt the password, and to compare that to pg_shadow. However, during my research I realized the need for double encrypting as per postgres clients.

So,another option is to use encryption on the web service xml using public / private keys, or using ssl to pass the md5 hash of the clients password.

The more elegant way seems to be using the encrypted web service, but the more universal method for clients would probably be ssl.

On Fri, Mar 16, 2012 at 11:39 AM, Bryan Montgomery <monty@english.net> wrote:
> Hello,
> We are looking at implementing a web service that basically makes calls to
> the database.
>
> I have been thinking about ways to secure the web service based on the
> database.
>
> I initially thought about just connecting to the database as the user with
> parameters passed through the web service - however I don't know how to do
> that other than clear text passwords.

It's a problem we have been looking at for some time in LedgerSMB,
actually.  So I have some thoughts on the topic.  PostgreSQL is
remarkably flexible here and so you have a bunch of options depending
on your needs.

The basic thing is you have to have re-usable credentials so things
like client cert auth, or httpd-digest won't work.  So the clients
have to pass the password to the web server in a way it can use them
to log in.
>
> So, is it possible for clients to encrypt their password and pass that
> through the web service to the database?

SSL protecting both the link from the client to the web service and
the web service to the db is what we recommend with LedgerSMB.  It's
the most versatile approach since it doesn't require any other
infrastructure.

Another approach would be to use Kerberos 5 auth on both sides and
pass the forwardable ticket through.  More secure but the client has
to be part of a KRB5 realm and configuration is a bit more complex.

> I was looking at the way postgres
> stores the users passwords but first of all I'm not sure if that is
> something the client could do. Then, if they could, how to go about
> connecting as a system user and verifying that the userid and password
> provided by the client are correct.

Ick...  I don't like that.  It requires too much knowledge and replay
vulnerabilities across the whole process.

Best Wishes,
Chris Travers