[Pki-devel] replication of new/modified profiles

[Dmitri Pal]

On 06/30/2014 03:28 PM, Endi Sukma Dewata wrote:
> 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.
>

Makes sense.

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.