[Freeipa-users] Freeipa-users] Overall Design of Policy Related Components

[Rob Crittenden]

Simo Sorce wrote:
> On Tue, 2011-11-01 at 14:31 -0400, Adam Young wrote:
>> On 11/01/2011 01:04 PM, Rodney Mercer wrote:
>>> On Tue, 2011-11-01 at 12:00 -0400, freeipa-users-request at redhat.com
>>> wrote:
>>>> On 10/31/2011 05:20 PM, Rodney Mercer wrote:
>>>>> We have previously developed Solaris RBAC authorization within our
>>>>> application to validate users and roles to our application's
>>>> internal
>>>>> commanding capability using the definitions that populate the name
>>>>> service switch maps.
>>>>>
>>>>> I have been searching for a method for implementing similar
>>>> capability
>>>>> using RHEL and had found promise with the following proposed
>>>>> documentation for IPAv2:
>>>> We decided to back away from trying to provide central RBAC. Our
>>>> experience with multiple projects revealed that there is no one size
>>>> fits all solution regarding RBAC. But we were talking about geral Role
>>>> base access control model not specific RBAC as Solaris implemented it.
>>>> The Solaris RBAC is similar to sudo and HBAC combined together. Both
>>>> features are managed by IPA.
>>>> We also have SELinux policies on Linux that can constrain the root
>>>> access. The user SELinux roles management is on the roadmap but HBAC +
>>>> SUDO should give you the equivalent if not more functionality than
>>>> Solaris RBAC.
>>>> http://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/index.html
>>>>
>>>> Or you can use RHEL6.2 beta and see the docs about SUDO and HBAC
>>>> there.
>>> The RBAC structure that I speak of is contained within our application.
>>> Being able to have IPA clients request the XML blob of role mappings to
>>> internal application commanding authorizations is what I was looking
>>> for.
>>>
>>> Is it possible to create IPA Roles that mean nothing to IPA yet our
>>> independent application could query and use them with it's internal
>>> security mechanisms?
>>
>> Yes it is possible.  The role mechanism does not have to have any
>> permissions or privileges assigned to it, and they will show up as
>> "member of"  relations  in an LDAP query.
>
> IIRC only if you are authenticated.
>
> We constrict who can see memberof attributes in some of the subtrees to
> avoid disclosing what privileges users have unless you are authenticated
> to the directory.
>
> Simo.
>

And you'd have to update the set of objectclasses. You might also have 
problems managing role entries that have changed in this way.

You would probably be better off creating your own framework plugin to 
manage this type of object and put them into a new place in the LDAP tree.

rob