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

Rodney Mercer rmercer at harris.com
Wed Nov 9 16:30:49 UTC 2011


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-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? 
> >>>
> >>> 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





More information about the Freeipa-users mailing list