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

[Dmitri Pal]

On 06/04/2012 06:52 PM, Lucas Yamanishi wrote:
> 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?
>

Have you looked at the extensibility guide (attached)?
I has an overview of what it would take to extend the schema and plugins.
It is definitely doable but doing it in a generic way would be a huge
effort. It might be easier to gradually build the support of most common
extensions for most common cases. 

Alexander, this is the version from December. Is there any newer version?

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



-------------- next part --------------
A non-text attachment was scrubbed...
Name: freeipa-extensibility.pdf
Type: application/pdf
Size: 355019 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20120605/1f75e58d/attachment.pdf>