Re: Fwd: pros and cons of two security models - Mailing list pgsql-general
| From | Chris Travers |
|---|---|
| Subject | Re: Fwd: pros and cons of two security models |
| Date | |
| Msg-id | CAKt_ZfubCOXkK+4CBgHZFxjpNB6igFCWdoijgxKmXB-YJsDV7w@mail.gmail.com Whole thread Raw |
| In response to | Re: Fwd: pros and cons of two security models (Stephen Frost <sfrost@snowman.net>) |
| List | pgsql-general |
On Wed, Oct 3, 2012 at 6:25 PM, Stephen Frost <sfrost@snowman.net> wrote:
> Well, that's the tradeoff I see. It can be handled using a bunch ofIs it possible to proxy those client-side SSL credentials..? I've not
> different means. One that I have suggested is two-factor auth, where you
> require a client-side SSL cert with a specific issuing authority and a cn
> of the username that comes in under basic auth. We don't support that as a
> matter of course yet, but, the other option is to use kerberos.
seen that, personally, but I've heard of people doing it.. Would be
very interested in that possibility.
I wonder how you'd validate the certificate without being able to ask for something to be encrypted via a private key.
> I guess the what I am wondering is whether some of the pushback we get fromIf they're asking about specific authentication mechanisms, I don't
> some developers is really a different aspect of the "databases should be
> dumb information stores" mentality, which isn't really the way we are going
> or if there really are issues here we haven't considered.
think they're feeling like the database is a dumb data store... I'll
admit that I could be wrong there though.
Well, that hasn't been the request. The request has been for one role for the application to use in the db. I was going through the tradeoffs that I had seen. The arguments I have heard are:
1) If you are giving access to your db, then people can do things that aren't possible in the application itself (however here a lot of the business logic is contained in the database, and so I don't think this applies), and
2) A simple assertion that that doing things this way is "a security flaw" and that the abstraction of user accounts in the web application is a "necessary abstraction." The concern appears to be some sort of architectural concern and I don't really understand it, hence one reason for asking around a bit.
My thinking is that security needs to follow business logic and it is a mistake to have them on separate layers.
I wouldn't compromise on having one central authority for security and
> My general feeling is that centralizing the security in the database means
> a narrower security perimeter in the areas that matter, and that this
> mostly comes at the expense of easy multi-tenant hosting.
access control, particularly for a product such as LedgerSMB. Just my
2c though, I'm sure others have differing opinions.When we're using krb5/gssapi, we *don't* use the set role approach, we
> Out of curiosity, since you are using krb5/gssapi, why do you go through
> the set role? Why not just pass krb5 tickets around, since this represents
> a re-usable auth method itself?
just proxy the credentials, as you'd expect. We use the set role
approach when we *can't* use krb5/gssapi (we're supporting users outside
of our AD infrastructure- clients, subcontractors, etc). In those
cases, we still want a strong auth system, so we go to a solution such
as client-side certificates or hardware tokens, but those aren't
proxyable credentials (that I've seen anyway.. maybe there's a way to
do it now), and so, in those cases, we use the SET ROLE approach.
They had better not be proxyiable... However one thing I have considered is this:
1) Password auth using HTTP basic and an SSL connection, and
2) The web server checks the SSL client cert to ensure that the cn on the certificate matches the supplied username. If they don't match you just ask for new credentials. In this regard, basically a username/password combo is unlocked by a certificate and you don't get to use a password unless you have a certificate for the same username. The password itself is proxyable, and so you get essentially two perimeters:
a) The web app then can enforce two factor auth, and then
b) The web app can then use the username/password as proxyable credentials.
Yeah, it really isn't that hard once you know the correct
> Yeah. Of course AD integration with anything on Linux is not as simple as
> it looks, but it still isn't that painful once you get used to it.
'incarnations', which are actually in a few briefings/trainings I've
given and are online in various places...
I wrote a paper on doing AD integration for OpenSSL on Linux. I was rather... amused.... by the differences in in how service accounts are handled in AD (at least in 2007) vs MIT Kerberos.
Best Wishes,
Chris Travers
pgsql-general by date: