Re: [Freeipa-users] Freeipa-users] Overall Design of Policy Related Components
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 informa
Re: [Freeipa-users] Freeipa-users] Overall Design of Policy Related Components
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. -- Rodney Mercer Systems Administrator ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Freeipa-users] Overall Design of Policy Related Components
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? -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Freeipa-users] Overall Design of Policy Related Components
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-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? 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 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Freeipa-users] Overall Design of Policy Related Components
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-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? > > 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. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Freeipa-users] Overall Design of Policy Related Components
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? 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. 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. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Freeipa-users] Overall Design of Policy Related Components
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 Mercer Systems Administrator ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
