On Tue, 2011-11-08 at 19:24 -0500, Dmitri Pal wrote: > On 11/02/2011 10:26 AM, Rodney Mercer wrote: > > On Tue, 2011-11-01 at 20:57 -0400, Dmitri Pal wrote: > >> On 11/01/2011 01:04 PM, Rodney Mercer wrote: > >>> On Tue, 2011-11-01 at 12:00 -0400, freeipa-users-requ...@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? > >>> > >>> Could extending the dirsrv schema to include attributes to be accessed > >>> for the security of the independent application be created to work in > >>> conjunction with these custom defined roles? > >>> > >>> Having the IPA Server available to all hosts that run the application is > >>> what we desire. We use *_attr Name Service Switch maps to access these > >>> roles and attributes from our Solaris implementation. > >>> > >>> Unless I am mistaken, HBAC might give us options as to whom may run our > >>> applications on particular hosts, but it would not help in defining who > >>> could run the internal application directives that we seek to map to > >>> users roles. > >>> Sudo doesn't help for the internal commanding our application desires to > >>> control. > >>> > >>> Thanks for any ideas you can lend. > >>> > >>> Regards, > >>> Rodney. > >>> > >> Rodney, > >> > >> I have read other responses too but reply to your clarification. It now > >> makes more sense. > >> > >> I think that best approach would be to store this data in the special > >> part of the tree and develop plugins for manage it. > >> Would you be interested in investing in such an effort? > >> If so I would go dig some of the designs and ideas and share them with > >> you and everybody else. I think they were ubandoned before shaping up > >> will enough to have a discussion on the list. > >> I think we proposed some schema for storing Roles and related XML blobs. > >> We are also working on the extensibility guide so it will be a perfect > >> opportunity to test it out. > >> > >> What do you think? > >> > > Dmitri, > > > > I have been searching for some time for an elegant solution to our > > problem of porting this application RBAC configuration to RHEL from the > > proprietary Solaris platform solution that we currently have. > > > > I think that this is something that would benefit others that currently > > employee Solaris *_attr NSS maps for roles to migrate to an RHEL IPA > > solution. > > > > That said, I will need to have our management assign a developer to this > > effort. I think that is important to them as the requirements to > > implement application RBAC to our product on RHEL is imminent. > > > > I also think that employing IPA as a solution for our application > > running on other POSIX operating systems to take advantage of this > > proposed schema would be advantageous to us and others. > > > > I will respond to you as to resources as soon as I know more. > > > > Hello, > > Is there any update on this? > > Anyways please find attached two PDF files. > It is enough to read first several pages of the overall design to get > the idea of what we wanted to do. > The actual data store design is in the second document. > > Also in addition to that a guide on how to extend IPA is brewing and > soon will see the light of day (at least a draft). > That should have enough information to: > 1) Understand the design > 2) Plan the effort > 3) Implement it the right way. > > Patches welcome! >
Dmitri, Thank you for the documentation. I am drumming up support for the effort within our organization. At this time the interest appears to be there but resources are scarce. I believe that we may still be able to go forward as one of our customers desire these capabilities down the road, possibly as early as Spring 2012. I have one question: If there is a relatively quick implementation within FreeIPA, what is the typical timeline for the functionality to get moved into RHEL? I am passing along the design docs that you forwarded to me to the engineers and management that support the project. I hope to hear back soon as to their interest. Please keep us informed as to the availability of the extensibility guide. I will let you know as soon as I can as to resources from our end. Thanks again. Rodney. -- Rodney Mercer Systems Administrator _______________________________________________ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users