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 _______________________________________________ Freeipa-users mailing list [email protected] https://www.redhat.com/mailman/listinfo/freeipa-users
