[Freeipa-devel] Unifying the PKI and IPA Directory Server instances

[Nathan Kinder]

On 11/01/2011 10:08 AM, Ade Lee wrote:
> On Tue, 2011-11-01 at 12:49 -0400, Simo Sorce wrote:
>> On Tue, 2011-11-01 at 12:40 -0400, Richard Megginson wrote:
>>> ----- Original Message -----
>>>>
>>>>
>>>> We had a brief discussion on unifying the PKI and IPA Directory
>>>> Server instances. Here are my notes from it. Please fill out the
>>>> details and correct me if I've mis-stated anything below.
>>>>
>>>>
>>>> Issues:
>>>>
>>>>
>>>>
>>> Do IPA and PKI use different suffixes?
>> Currently not as we use completely separate instances, but we will be
>> able to use different suffixes for some stuff.
>>
> I would suggest that if we use the same database, then we use different
> suffixes.  For one thing, we will want to be able to set ACIs so that
> the information here is not publicly browsable.
>
> It will also be much easier to limit the pki users ability to touch the
> rest of the db, and visa versa.
>
> It also makes it less likely that upgrade scripts will stomp on each
> other.
We really should use separate suffixes/backends for the reasons above in 
addition to other benefits.  Replication is at the suffix level, so this 
adds the ability to not replicate PKI data is that is something we ever 
decide we need to do.  Indexes are also configured at the suffix/backend 
level, so we can have separate indexes defined for the PKI and IPA user 
trees.
>>>>      1.
>>>>
>>>> Both make changes to Config. One identified conflict is he
>>>> configuration of the Uniqueness plugin
>>> It may be easy to enhance this plugin and other plugins to allow different configuration per subtree.
>> If we confirm this conflict this will become a requirement before we can
>> proceed.
What is this conflict?  Many of our plug-ins have this ability already, 
and we should add it where it is missing.  The RHDS documentation shows 
that the attribute uniqueness plug-in can be configured by subtree already.
>>>>      2.
>>>>
>>>> PKI uses Directory Manager. This is insecure. Can it use a differen,
>>>> limited admin?
>>> Or use ldapi?  I don't think ldapjdk can use ldapi.
>> It's a matter of trust for me. I do not want to trust PKI to have free
>> reign on all data. I want it to be confined to only what it needs.
>>
>> So we can use ldapi and user mapping, but we wouldn't map the user to DM
>> anyway.
Agreed.  If the roles were reversed, we would not want IPA to be able to 
have free reign on the PKI data.  It makes sense to have separate admin 
roles and only use DM where absolutely necessary.
>>>>      3.
>>>>
>>>> Index strategies are different
>>> Use a union?  e.g. if ipa needs attribute "a" indexed for equality only, but PKI needs it indexed for presence and substring only, then we can just index it for eq, sub, and pres.
If we use separate suffixes/backends, we can configure the indexes 
differently.
>> The problem here is finding out and how to make sure pki vs ds/ipa
>> install and upgrade scripts do not stomp on each other.
>>>>      4.
>>>>
>>>> make sure we have a union of the required sets of plugins
>>>>      5.
>>>>
>>>> PKI needs to set D.S. Default Name context
>>> What is this?
>> See my other mail, we need DS to support setting defaultNamingContext in
>> rootdse.
Is there a RFE opened against 389 for this already?  It should be pretty 
easy to add the ability to configure a default naming context to be 
displayed in the rootDSE.
>>>>      6.
>>>>
>>>> If PKI uses the IPA datastore for users, it needs to creat the user
>>>> with all the right prerequisites (object class, defaults)
>>> If both PKI and IPA use structural objectclasses, we may have to create corresponding auxiliary objectclasses so that you can mix-in both sets of objectclasses while having only one structural objectclass per entry.
>> The problem here is much bigger, PKI simply do not have enough
>> information to create a proper IPA user, so it should not be allowed to.
>> This is an example of why I want to tightly control through ACIs what
>> PKI can do and prevent it from causing "issues".
>>
> If we do this integration, then I'm OK with IPA creating the users.
>
>> Simo.
>>
>
> _______________________________________________
> Freeipa-devel mailing list
> Freeipa-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel