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
[email protected]
https://www.redhat.com/mailman/listinfo/freeipa-devel
_______________________________________________
Freeipa-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/freeipa-devel
