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

_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Reply via email to