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

[Adam Young]

On 11/03/2011 12:56 AM, Simo Sorce wrote:
> On Wed, 2011-11-02 at 20:25 -0400, Adam Young wrote:
>> On 11/02/2011 06:19 PM, Rob Crittenden wrote:
>>> Simo Sorce wrote:
>>>> On Wed, 2011-11-02 at 16:44 -0400, Ade Lee wrote:
>>>>> On Wed, 2011-11-02 at 16:03 -0400, Adam Young wrote:
>>>> [...]
>>>>> So, a user becomes an agent on the ca by having a certificate in the
>>>>> user record and being a member of the relevant admin, agent or auditor
>>>>> group.
>>>>>
>>>>> I see this as follows:
>>>>> 1. ipa cms-user-add (add a user and add the auxilliary cmsuser object
>>>>> class)
>>>>> 2. ipa user-cert (contact the ca and get a certificate for this user,
>>>>> add this cert to the user record in the ipa database)
>>>>> 3. ipa group-add-member (add the user to the relevant group)
>>>>>
>>>>> At no point does PKI need to modify anything in the IPA database.
>>>> Sounds reasonable.
>>>> Can you post a link to the schema that would be added to IPA objects ?
>>>>
>>>> Simo.
>>>>
>> I think this is it:
>>
>> http://svn.fedorahosted.org/svn/pki/trunk/pki/base/ca/shared/conf/schema.ldif
>>
>> Look for cmsuser.
> Unfortunately it looks like the cmsuser objectclass is of type
> structural, which means it cannot be added to existing records.
>
>> The cert seems to  comes from
>>
>> 05rfc4523.ldif
>>
>> and is added in
>>
>> 06inetorgperson.ldif
>>
>> Which is already in our user record.
>>
>> CMS only seems to "require" usertype, which is a string, and "allows"
>> userstate  which is an integer.
> I wonder if we can convince PKI to use a different schema to reprsent
> this information. We can use Roles or Groups to tell what type of user a
> user is, not sure about the state as that schema file has exactly the
> same comment for both usertype and userstate, seems a bug.

I think so.  I do not know if CMSuser is really needed, as it looks like 
everything in there is accounted for some other way.

My guess is the "type"  field is used to enforce that someone in one 
group,  say agents, cannot also be in a different group, say "auditors" 
but they do use groups for  most roles in the system.

I think that there are going to be severl layers for the permissions in 
the IPA approach:  For CAAdmins, we create a group CAdmins, and  add a 
Role to to CAAdminRole which contains the appropriate Permissions.  Same 
for Auditors and agents.  No one should have the ACI to change these roles.

We probably want to put in an RFE for IPA Roles  that state two roles 
are mutually exclusive.


userstate is, I think, to disable an account, which is handled using 
nsaccount lock  in IPA.  I think we should agree on a single mechanism, 
and it should be the one in the most standard schema.





>
>>> IIRC the user we create in CS now has the description attribute set up
>>> in a very specific way. Is that still required?
> What is description used for ?
>
> Simo.
>
>