Chris, * Chris Travers (chris.travers@xxxxxxxxx) 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
Attachment:
signature.asc
Description: Digital signature
