Ade, I think the high-level design captured most of what we discussed that day. One thing I'd like to propose is that since all subsystems, including the now being rewritten Tomcat TPS, share the same authentication and authorization plugin framework, I hope your design/implementaton is not limited to DRM. Therefore I hope the new context ldap attribute is to be added to all the agent-managed data records (certs, requests, key records, etc.). Also, even though the use case that triggered this design was due to support for different applications, internally within a CS system, it is just some kind of "security scope", and we do want to support deployments where the same application is used but multiple "security scopes" are defined (e.g. ipa1, ipa2, pkiuser1, pkiuser2, etc.),. Therefore, instead of calling it "application", I'd suggest that we think of it as a "scope" or something like that, and name them appropriately in code and documentation. Also, we did talk about the ability to assign multiple groups to the same user. I expect the existing authentication and authorization framework to be used (with modification, if necessary). In this case, I have a question. That is, how do you efficiently identify the scope that the user intends to manage? Perhaps we need to allow agents to specify their scope in the uri so that the backend knows which scope to authenticate/authorize? Would we then allow same id across different scopes? About what you suggested in the CS.cfg regarding allowing multiple authentication dbs. Is the following what you have in mind? First, the java cs subsystems has a framework for both the authentication and authorization plugins. e.g. auths.impl.AgentCertAuth.class=com.netscape.cms.authentication.AgentCertAuthentication auths.instance.AgentCertAuth.agentGroup=Certificate Manager Agents auths.instance.AgentCertAuth.pluginName=AgentCertAuth where each plugin defines its own set of required config params. So, with the example auth dbs definitions in CS.cfg that you provided on the wiki, We could now then add something like auths.instance.AgentCertAuth.authdb=ipa ? BTW, back to what I suggested on not using the word application, I'd suggest the following scope definitions instead: SecurityScope.contexts=pkiuser,barbican,ipa,dnssec,... SecurityScope.default=pkiuser SecurityScope.ipa.authdb.hostname=... SecurityScope,ipa.authdb,port=... etc So the new auths parameter would be something like this instead: auths.instance.AgentCertAuth.SecurityScope=ipa I assume the authentication and authorization db will always be the same, whichever the authentication scope points to? I will await your detailed design with much anticipation. Christina On 03/13/2014 07:13 AM, Ade Lee wrote: