[Freeipa-users] Freeipa-users Digest, Vol 46, Issue 104

[Lucas Yamanishi]

On 05/17/2012 10:47 AM, Lucas Yamanishi wrote:
>> On 05/17/2012 09:34 AM, Rob Crittenden wrote:
>>> Lucas Yamanishi wrote:
>>>> Hi everybody,
>>>>
>>>> I've added some custom schema to my directory, but it's useless to me if
>>>> if I can't control read permissions on it.  This is obviously a little
>>>> tricky since (Free)IPA allows everybody to ready everything by default.
>>>>   With that, what's the best way to restrict access to user attributes?
>>>> Is there anything like this in the roadmap?
>>> Right now there is are no plans to support deny ACIs natively in the
>>> permission plugin. That isn't set into stone, we just need some convincing.
>> Then let me make the case:
>>
>> I know IPA is aimed mainly at authentication and authorization, but it
>> provides enough base schema and tree structure to do basic asset and
>> personnel management.  More importantly, it's easier to setup than a
>> pure 389 Directory.  This makes it ideal for small to medium sized
>> organizations that don't need the extra utility a separate directory
>> provides.  Additionaly, the well-designed webui makes it easy to
>> delegate tasks to non-technical personnel.  The requirements to achieve
>> this end are two: add native support for a restricted set of schema
>> extensions and fine-grained access controls to those attributes.
>>
>> For schema extensions, support could (and should) be limited only to
>> additional attributes on a restricted set of existing objects.  For
>> example, additions to users and hosts.  This would satisfy requirements
>> for a majority of small to medium sized organizations, I'd think.
>
> Building a generic mechanism is really a lot of work.
> It might be simpler to do it differently, i.e. incrementally add support
> for additional attributes.
> Do you have the schema that you added handy?
> What is the application that uses it? Is it popular? Is it open source?
> If it is it might make sense to just support these attributes our of box
> if the schema is loaded.

Mostly I'm talking about truly custom schema, like you would create
after obtaining an enterprise OID.  A few things I'm adding are hire
date, emergency contact, previous employer and badge number.  Human
Resources stuff.  Once I get it all hammered out I'll send you a copy.

As far as standardized schema goes, a lot of the attributes I need are
in RFCs 4519 and 4524.  Things like organizationName,
organizationalUnitName, organizationalStatus, personalTitle,
homePostalAddress and/or postalAddress.  Again, HR stuff-- and that's
what I'm talking about.  Your system already tracks user accounts very
well.  Why not extend it to track them as fully fledged people?

-- 
-----
*question everything*learn something*answer nothing*
------------
Lucas Yamanishi
------------------
Systems Administrator, ADNET Systems, Inc.
7515 Mission Drive, Suite A100
Lanham, MD 20706 * 301-352-4646 * 0xE23F3D7A