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

[Alexander Bokovoy]

On Tue, 05 Jun 2012, Dmitri Pal wrote:
>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?
There is no newer version. I was planning to go over and add more
content in the schema extension area once we get 3.0beta1 out.


-- 
/ Alexander Bokovoy