[Pki-devel] DRM authentication discussion (preliminary design)

Christina Fu cfu at redhat.com
Fri Mar 14 23:27:36 UTC 2014


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:
> I've written up a very high level design based on what we discussed
> yesterday.  Please provide comments so we can flesh it out further.
>
> http://pki.fedoraproject.org/wiki/Enhancing_DRM_Authentication_and_Authorization
>
> Thanks,
> Ade
>
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel




More information about the Pki-devel mailing list