> > Thanks Mike, I did understand you correctly the first time. I still maintain that’s in the realm of authentication, not authorization, and should be cleanly separable from the problem of implementing per-document access controls. >
Then I think we're saying the same thing except I'm looking/asking about the actual intended mechanics of this particular cross domain case. I agree access controls are an authorization question, but what the heck is getting authorized and how do those things map to whatever gets authenticated? I was specifically proposing the idea that "role entities", stored inside the database, are the only objects an authorization record could get granted permissions to as a proposed nomenclature. * Roles are authorized. * Users are authenticated. * Users are a server/system level entity. * Roles are a database level entity. * The valid role list replicates with the database. * The document authorization descriptors replicate with the database. * The users database does not replicate. * The links between users and roles do not replicate. And there is this big ol' security question about what data in the database replicates to another site? If I get a replica of a database from your server, what, if anything, prevents me from granting myself access controls to the entire database? If I get a replica of a database, how does that map my preexisitng autheticated user entities onto the authorized entities of the access control docs? (If there's an authorized entity called 'sam' in the access controls, do I just create a user account called 'sam' with a password I know so I can autheticate as 'sam', and get access to Sam's doc authorizations?) The response of "this is an authentication versus authorization issue and we're discussing authorizations" is something I agree with; but it doesn't seem to address my question/observation that there is a linking relationship between the authenticated and authorized entities; and in a cross domain replicated environment the adminstrative controls for assigning the links and creating the respective entities are under differing authorities/controls. IOW, defeating Couch Access Controls looks like it will simply be pulling the database onto your own server and granting yourself access. That doing something more sophisticated will require a domain aware approach to defining authenticated and authorized entities... Is the intended design architecture a simple 'string match on the authenticated user name' model? IOW, is the user/authorization linking model that every user named 'sam' is accepted/authenticated as the same 'sam' regardless of hosting server, and therefore all users named 'sam' on every server are always authorized the same way? I think it's obvious that while a valid way to handle it, that's clearly suboptimal and in some cases will be completely unusable. I agree access controls are an "authorization" question; my questions/concerns/focus is "What conceptual entity are these access control documents authorizing" and "How do authenticated entities get mapped to those authorized entities"? Specifically in a cross domain setting where the authentication systems are under totally different administrative domains; and each domain can effectively admin itself over the entire DB. If you have bi-directional replication between two servers as I described before (the shared product catalog); is there a design element here to enforce those access controls in "cross domain safe" way? I'm not saying there has to be, but I do think that'd be a good thing, and I don't see an immediately obvious 'how to do it' solution... Thanks, Mike
