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*
Systems Administrator, ADNET Systems, Inc.
7515 Mission Drive, Suite A100
Lanham, MD 20706 * 301-352-4646 * 0xE23F3D7A
Freeipa-users mailing list