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

[Adam Young]

On 11/03/2011 11:00 AM, Ade Lee wrote:
> On Thu, 2011-11-03 at 09:20 -0400, Adam Young wrote:
>> 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.
>>
>>
> With just an initial look at the dogtag code, it appears that userState
> and userType are no longer used in any meaningful way.  We'll have to do
> a more exhaustive search to be sure, but initial indications are that we
> may no longer need this object class.
>
> Adam does bring up a good point, which is that - as a common criteria
> requirement, users were required to have no more than one of the
> following roles: agent, admin, auditor.  How would this be enforced in
> the IPA database?

I think that we need to make it an RFE for IPA.




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