[Pki-devel] replication of new/modified profiles

[Endi Sukma Dewata]

Hi, I have some comments about the design:
http://pki.fedoraproject.org/wiki/LDAP_Profile_Storage

I think all system/default profiles should remain file-based and all 
custom profiles should be LDAP-based. It will make a clean separation: 
system profiles are owned by us (Dogtag developers), custom profiles are 
owned by the admin.

The system profiles will be read-only. This way we will be able to 
update the system profiles without writing any upgrade scripts because 
the files will be updated automatically by RPM. Just one requirement, 
all server instances must be upgraded to the same version.

If the admin wants to change a system profile, they can clone it into a 
custom profile and make the changes there. The custom profiles cannot 
have the same names as the system profiles, so there's won't be any 
conflict/confusion, and no need to support a "restore" command. In 
general we won't need to write upgrade scripts for custom profiles 
except if we change the LDAP schema.

About the schema itself, I suppose we want to have something that 
resembles the actual Profile data structure (see ProfileData Java 
class). There should be an LDAP attribute for each single-valued Java 
attribute (e.g. name, description, enabled, visible). This way the 
profile is more manageable and can be queried based on these attributes. 
For collection attributes (e.g. inputs, outputs, policySets) we can use 
child LDAP entries to represent them.

About the names, right now we use "profile" to refer to both cert 
profile in CA and token profile in TPS. We probably should use separate 
terms to distinguish them (e.g. CertProfile and TokenProfile). This 
applies to Java/Python class names, REST interface, CLI, LDAP schema, etc.

So the LDAP entries for a profile may look like this:

dn: cn=MyUserCert,ou=Profiles,ou=CA,{suffix}
objectClass: certProfile
cn: MyUserCert
displayName: Manual User Dual-Use Certificate Enrollment
description: This certificate profile is for enrolling user certificates.
visible: true
enabled: true
enabledBy: admin

dn: ou=Inputs,cn=MyUserCert,ou=Profiles,ou=CA,{suffix}
objectClass: organizationalUnit
ou: Inputs

dn: cn=i1,ou=Inputs,cn=MyUserCert,ou=Profiles,ou=CA,o=pki-tomcat
objectClass: pkiCertProfileInput
cn: i1
classId: keyGenInputImpl

About the REST interface & CLI, since this will be the primary way to 
edit profiles, we might want to have more granular commands to modify 
parts of the profile. Right now with ca-profile-mod command you need to 
send the entire profile in a file. It would be nice to be able to 
specify some parameters to change certain attributes only, or use 
separate commands to manage the inputs/outputs.

We'll also need an interface to find existing cert records that use a 
certain profile and bulk modify them to use a different profile. This 
will be useful when you create a clone to change the system profile.

I'm not sure if we should support 10.2 -> 10.3 cloning. When we release 
10.3 the 10.2 will still be fairly new so it might be reasonable to 
require all clones to be upgraded. It will reduce the amount of testing 
requirement too.

-- 
Endi S. Dewata

On 6/18/2014 2:44 AM, Fraser Tweedale wrote:
> Hi all,
>
> A requirement from the FreeIPA side is the ability to add and
> customise CA profiles.  Dogtag's current profile creation behaviour
> writes the new profile to the filesystem beside the standard
> profiles (as well as making the appropriate update to the registry,
> etc.)
>
> There does not seem to be a mechanism to distribute new/modified
> profiles to replicas - though perhaps I have missed something.
>
> Because this behaviour is required, unless I have overlooked
> something or there is a better way (in which case please shout out),
> I think it makes sense to begin a design proposal for an LDAP-based
> profile store.
>
> Finally, a brief mention of some tickets related to profile storage
> that could be good to tackle simultaneously should the proposed
> change go ahead:
>
> - https://fedorahosted.org/pki/ticket/778
> - https://fedorahosted.org/freeipa/ticket/4002
>
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel
>