Re: Fwd: pros and cons of two security models

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 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.

> 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.

> 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...

Thanks!

Stephen