Re: Fwd: pros and cons of two security models

On Wed, Oct 3, 2012 at 6:25 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:

> Chris,
>
> * Chris Travers (chris(dot)travers(at)gmail(dot)com) wrote:
> > Well, that's the tradeoff I see. It can be handled using a bunch of
> > 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.
>
> Is it possible to proxy those client-side SSL credentials..? I've not
> 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
> from
> > 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.
>
> If they're asking about specific authentication mechanisms, I don't
> 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.

>
> > 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.
>
> I wouldn't compromise on having one central authority for security and
> access control, particularly for a product such as LedgerSMB. Just my
> 2c though, I'm sure others have differing opinions.
>
> > 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?
>
> When we're using krb5/gssapi, we *don't* use the set role approach, we
> 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. 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.
>
> Yeah, it really isn't that hard once you know the correct
> '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