[Freeipa-devel] Who can make the CA requests

[Dmitri Pal]

Hi,

We are building the integration of the CA into the IPA. The CA will be 
silently installed together with IPA. The CA will have access to the 
IPAs DS and will use it as its own back end storage.
The interaction with CA will be done via RA (Registration Authority). 
The RA will have a secure connection to CA. There are several operations 
that can be performed against CA. Among them :
a) Request a new certificate
b) Renew a certificate
c) Revoke certificate
d) Check the status of the request
(may be others, Andrew please confirm)

The CA will perform the whatever action the RA has requested in v2. 
There is no CA management interface planned. Also there is no plan for 
approval process in v2. If the request made through the RA to CA it will 
be trusted and executed. These limitations create a requirement to 
validate user permissions before passing a request to RA in the XML-RPC 
back end. Since there would be no other way to call the RA and thus get 
access to CA, implementing access control enforcement point in the 
XML-RPC back end management plugin will be sufficient.
The XML-RPC management plugin would have to check if the current user 
who runs the session is authorized to access RA and make calls to CA. 
There are different ways we can implement this access control 
enforcement check:
a) We can define a special group that can perform certificate operations 
and hard code it in the management plugin. The management plugin will 
just check if the user is a member of the group and if he is it will 
proxy the request to RA and thus to CA. This approach is inflexible and 
not granular. Though it is simple it might not be acceptable for v2.
b) The approach can be improved  by creating  an entry in the cn=config 
area that would contain the name of the group instead of hard coding the 
name of the group in the  plugin. We can add more granularity by having 
an attribute per  operation  thus allowing grunting different right to 
different groups of people.  This approach is generally better but still 
does not match the overall ACI based access control morel used in IPA.
c) The ACI based approach can also be implemented in different ways. For 
example we can say that the operations mentioned above map in the 
following way to the DS permission on a attribute:
* Request a new certificate - add an attribute
* Renew a certificate - update an attribute
* Revoke certificate - delete an attribute
* Check the status of the request - read an attribute
Using this approach we can define ACIs for example for the 
userCertificate attribute. When the user tries to ask for a new cert  
the managment plugin will get the rights regarding userCertificate 
attribute. If current user is allowed to add userCertificate attribute 
he will be allowed to request a new certificate via RA. If he is allowed 
to edit the userCertificate attribute the user will be allowed renew the 
cert and so on. Such approach will work for a special CA case but it is 
not generic.
d) If we want to make the solution more generic and be able to handle 
other cases in a plaggable way we would need create a mapping between 
entry points advertised in the XML-RPC frame work and some attributes. 
In most cases we do not need this since the XML-RPC call will deal with 
the DS entry and its rights will dictate what a user can do. But in the 
case of where there is no actual direct DS modification happening we 
would need a mapping. We can create a configuration object with a multi 
valued attribute. This attribute will contain a triplet:
   entrypoint name; attribute; right
The XML-RPC framework will read this configuration entry at the 
initialization moment and create an internal lookup table. For each XML 
RPC entry it will do a lookup in this table before executing the entry. 
If there is no mapping then the entry will be executed. If the entry is 
mapped to some attribute and the right the framework will check (using 
Get Effective Rights feature of DS) if the user has a specified right 
against the specified attribute. If the user has the right, the entry 
point will be invoked, if not then the exception will be risen and the 
event will be logged.
This approach is generic and if implemented once inside the framework 
itself, there is no need to implement something like this for any other 
use case. It would be enough to just add an attribute with the mapping 
to the configuration entry. This will make the IPA management framework 
be attractive for additional extensions.

Well the generic approach is most always more work. But it does not seem 
to be in this case and Jason most likely already thought about this issue.
Does everybody agree that the d) approach is the way to go?

Is userCertificate attribute the right attribute to map the access 
control decision to when we need to do a cert operation? May be it would 
be better to  define a new attribute per operation and map the 
operations to those "virtual" attributes (and object class) rather than 
real attributes that can be defined in an entry. This way we would be 
able to accomplish maximum granularity.

Any comments or suggestions are welcome!

Thank you,
Dmitri