thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig Artley <cart...@hotmail.com>
Subject RE: username/password - security in Apache Thrift
Date Wed, 25 Sep 2013 20:01:41 GMT
I guess I am not that clever; I need an example or how-to. I would like to add password authentication
to a thrift service, and I think there must be a way to layer in something that knows how
to use the local password file or LDAP or whatever. The last thing I want to do is authenticate
the password myself, because I'm sure whatever I came up with would not be "secure" by any
reasonably thorough definition of security.

Thanks for the pointers on TLS-SRP.  I'll take a look and see if I can figure it out.

  -craig

> Date: Wed, 25 Sep 2013 12:09:00 -0700
> Subject: Re: username/password - security in Apache Thrift
> From: george@glympse.com
> To: user@thrift.apache.org
> 
> And it's worth noting that authentication via client side certs is a
> "standard, reliable, vetted mechanism" that is already layered into Thrift
> via its support for SSL.
> 
> un/pw authentication is typically considered an application layer concern.
> I've not heard of TLS-SRP until now...that's cool!
> 
> 
> On Wed, Sep 25, 2013 at 11:11 AM, Ben Craig <bencraig@apache.org> wrote:
> 
> > > Does the thrift user have to build all the user authentication into
> > > the protocol? It seems like there should be some standard, reliable,
> > > vetted mechanism that could be layered into Thrift.
> >
> > Sending a username and password over an SSL connection is a very common
> > pattern.  It is difficult for Thrift to do "everything" here, because
> > Thrift doesn't have access to whatever the backing database is that stores
> > the usernames and passwords.
> >
> > If you are looking for something that uses the username and password as
> > the only forms of authentication (in lieu of certificates), then you
> > should investigate TLS-SRP (http://en.wikipedia.org/wiki/TLS-SRP).  You
> > would likely need to create a new transport class to wrap TLS-SRP.
> >
 		 	   		  
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message