Re: [Freeipa-users] Multi-tennancy and Freeipa
On 12/16/2011 03:41 PM, Dmitri Pal wrote:
On 12/16/2011 02:37 PM, Alan Evans wrote:
Adam,
This is great news. The feedback I have after a quick read through (I
will try to put a bit more time on it later) would be to make the
'tennant' separation more flexible and why not use existing ldap
schema?
Instead of forcing the user into cn={TENANT},cn=tenants,$suffix why
not create a 'tennant' aux class that would allow the end user to
design a DIT however they would like.
We for example use o=company|organization,$suffix. Then any schema
maintenance instead of being:
For each tennant in (cn=tenants,$suffix)
It would be:
For each tennant in (ldapsearch (objectclass=tennant))
Then the end provider could design a DIT that fit their needs with
replication in mind. Consider the flexibility of:
o=Tennant1,C=US,$suffix
o=Tennant2,C=UK,$suffix
o=Tennant3,OU=North America,$suffix
o=Tennant4,OU=Europe,$suffix
That's my 2¢ at the moment. I'd be glad to banter back and forth
about this with you. :)
Regards,
-Alan
This is very flexible but I am not sure IPA would be able to be that
flexible.
One of the design goals from the beginning was: static schema and flat
DIT. The whole project is built around it. Such approach would really
come as a system shock. I am not against it, just saying it would be
harder as it goes even further than Adam's proposal in changing the
fundamental principals.
Also, it is not just the user table that we need to segregate but the
entire DIT. Roles, Groups, SUDO, HBAC, and so forth all need to be
segregated into a separate subtree, not just the user lists. So putting
users in a aux class doesn't really support sufficient segregation. The
assumption for us is that the IPA base scheme would be for
administrative machines, and then each of the tenant subtrees would be
for a subset of the machines in the system.
But that is really only one view of it, and I think I can see where you
are coming from: you want to be able to manage,say customers, but use
the same rules for them as you do for employees?
On Fri, Dec 16, 2011 at 5:35 AM, Adam Youngayo...@redhat.com wrote:
I opened a ticket for multitenancy
https://fedorahosted.org/freeipa/ticket/2201
Here is a detailed write up of the issues.
http://freeipa.org/page/Multitenancy
Please provide any feedback that you have and I will update.
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Multi-tennancy and Freeipa
On 12/16/2011 02:37 PM, Alan Evans wrote:
Adam,
This is great news. The feedback I have after a quick read through (I
will try to put a bit more time on it later) would be to make the
'tennant' separation more flexible and why not use existing ldap
schema?
Instead of forcing the user into cn={TENANT},cn=tenants,$suffix why
not create a 'tennant' aux class that would allow the end user to
design a DIT however they would like.
We for example use o=company|organization,$suffix. Then any schema
maintenance instead of being:
For each tennant in (cn=tenants,$suffix)
It would be:
For each tennant in (ldapsearch (objectclass=tennant))
Then the end provider could design a DIT that fit their needs with
replication in mind. Consider the flexibility of:
o=Tennant1,C=US,$suffix
o=Tennant2,C=UK,$suffix
o=Tennant3,OU=North America,$suffix
o=Tennant4,OU=Europe,$suffix
That's my 2¢ at the moment. I'd be glad to banter back and forth
about this with you. :)
Regards,
-Alan
This is very flexible but I am not sure IPA would be able to be that
flexible.
One of the design goals from the beginning was: static schema and flat
DIT. The whole project is built around it. Such approach would really
come as a system shock. I am not against it, just saying it would be
harder as it goes even further than Adam's proposal in changing the
fundamental principals.
On Fri, Dec 16, 2011 at 5:35 AM, Adam Young ayo...@redhat.com wrote:
I opened a ticket for multitenancy
https://fedorahosted.org/freeipa/ticket/2201
Here is a detailed write up of the issues.
http://freeipa.org/page/Multitenancy
Please provide any feedback that you have and I will update.
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
--
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
[Freeipa-users] Multi-tennancy and Freeipa
Can Freeipa accommodate a mufti-tennant environment? i.e. I work for a managed service provider that currently uses LDAP for authentication for both our users and our customer's users. But Customer A cannot see Customer B's data due to access control on our directory. Each customer has at least one LDAP service account in their container in the tree that can only view that customer's container and my company container. Would we have to do something like create realms for each customer? Then configure trusts from customer realm to ours? EXAMPLE.COM - our realm CUSTOMERA.EXAMPLE.COM - customer a realm ... so on What about data within the directory? Currently our DIT is like: o=MyCompany,dc=example,dc=com o=CustomerA,dc=excample,dc=com Would seperating by realms automatically divide that up? What about would Customer A be able to see any Customer B users using multiple realms alone or would we have to take additional precautions? Regards, -Alan Posted on behalf of Alan -- 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] Multi-tennancy and Freeipa
On Wed, 2011-09-14 at 11:36 -0400, Dmitri Pal wrote: Can Freeipa accommodate a mufti-tennant environment? i.e. I work for a managed service provider that currently uses LDAP for authentication for both our users and our customer's users. But Customer A cannot see Customer B's data due to access control on our directory. Each customer has at least one LDAP service account in their container in the tree that can only view that customer's container and my company container. At the moment we do not have the ability to move accounts into sub containers. It is a feature we may want to implement in future, but we kept the tree intentionally flat to avoid misuse we've seen as quite common in products like AD. Would we have to do something like create realms for each customer? Then configure trusts from customer realm to ours? EXAMPLE.COM - our realm CUSTOMERA.EXAMPLE.COM - customer a realm ... so on This may work onve ipa v3 is out. Building multiple realms (in multiple servers/VMs) is possible but trust relationship management is not fully backed in yet. What about data within the directory? Currently our DIT is like: o=MyCompany,dc=example,dc=com o=CustomerA,dc=excample,dc=com If you create multiple realms you'll have to do it with multiple servers with current IPA. Would seperating by realms automatically divide that up? What about would Customer A be able to see any Customer B users using multiple realms alone or would we have to take additional precautions? In general ACIs can be used to limit who sees what. It may be possible to use the current flat view on the server and constrain access to specific users/groups using a bit of custom schema in order to label entries, and custom ACIs. Of course you would want to turn off anonymous access to the directory and encrypt all traffic with SSL or GSSAPI at that point. 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] Multi-tennancy and Freeipa
On Wed, 2011-09-14 at 15:08 -0400, Simo Sorce wrote: On Wed, 2011-09-14 at 11:36 -0400, Dmitri Pal wrote: Can Freeipa accommodate a mufti-tennant environment? i.e. I work for a managed service provider that currently uses LDAP for authentication for both our users and our customer's users. But Customer A cannot see Customer B's data due to access control on our directory. Each customer has at least one LDAP service account in their container in the tree that can only view that customer's container and my company container. At the moment we do not have the ability to move accounts into sub containers. It is a feature we may want to implement in future, but we kept the tree intentionally flat to avoid misuse we've seen as quite common in products like AD. Would we have to do something like create realms for each customer? Then configure trusts from customer realm to ours? EXAMPLE.COM - our realm CUSTOMERA.EXAMPLE.COM - customer a realm ... so on This may work onve ipa v3 is out. Building multiple realms (in multiple servers/VMs) is possible but trust relationship management is not fully backed in yet. What about data within the directory? Currently our DIT is like: o=MyCompany,dc=example,dc=com o=CustomerA,dc=excample,dc=com If you create multiple realms you'll have to do it with multiple servers with current IPA. Would seperating by realms automatically divide that up? What about would Customer A be able to see any Customer B users using multiple realms alone or would we have to take additional precautions? In general ACIs can be used to limit who sees what. It may be possible to use the current flat view on the server and constrain access to specific users/groups using a bit of custom schema in order to label entries, and custom ACIs. Of course you would want to turn off anonymous access to the directory and encrypt all traffic with SSL or GSSAPI at that point. Replying to myself, custom schema may not be necessary. It may be possible to use just ACIs and non-posix groups together w/o adding additional schema, that would make the problem simpler, although ACIs need to be built carefully not to cripple the admins view. 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] Multi-tennancy and Freeipa
On Wed, 2011-09-14 at 15:19 -0400, Rob Crittenden wrote: Simo Sorce wrote: On Wed, 2011-09-14 at 15:08 -0400, Simo Sorce wrote: On Wed, 2011-09-14 at 11:36 -0400, Dmitri Pal wrote: Can Freeipa accommodate a mufti-tennant environment? i.e. I work for a managed service provider that currently uses LDAP for authentication for both our users and our customer's users. But Customer A cannot see Customer B's data due to access control on our directory. Each customer has at least one LDAP service account in their container in the tree that can only view that customer's container and my company container. At the moment we do not have the ability to move accounts into sub containers. It is a feature we may want to implement in future, but we kept the tree intentionally flat to avoid misuse we've seen as quite common in products like AD. Would we have to do something like create realms for each customer? Then configure trusts from customer realm to ours? EXAMPLE.COM - our realm CUSTOMERA.EXAMPLE.COM - customer a realm ... so on This may work onve ipa v3 is out. Building multiple realms (in multiple servers/VMs) is possible but trust relationship management is not fully backed in yet. What about data within the directory? Currently our DIT is like: o=MyCompany,dc=example,dc=com o=CustomerA,dc=excample,dc=com If you create multiple realms you'll have to do it with multiple servers with current IPA. Would seperating by realms automatically divide that up? What about would Customer A be able to see any Customer B users using multiple realms alone or would we have to take additional precautions? In general ACIs can be used to limit who sees what. It may be possible to use the current flat view on the server and constrain access to specific users/groups using a bit of custom schema in order to label entries, and custom ACIs. Of course you would want to turn off anonymous access to the directory and encrypt all traffic with SSL or GSSAPI at that point. Replying to myself, custom schema may not be necessary. It may be possible to use just ACIs and non-posix groups together w/o adding additional schema, that would make the problem simpler, although ACIs need to be built carefully not to cripple the admins view. Simo. The management framework only supports a single realm as well, even if you could manage to insert the data. The ACIs solution would work with a single-realm model ... except that it also means each customer needs to do very careful access control when using kerberos for now, as we do not have a way to constrain which users can get tickets for which services in the same REALM. This is something we want to introduce in v3.0 anyways for various reasons. So going forward, segmentation of users should become simpler. 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] Multi-tennancy and Freeipa
Thanks all for your quick replies. My case is a bit of a corner case anyway so I was not expecting to have a perfect solution. Having tested out freeipa a few times in the last couple years it is certainly impressive the progress that has been made. I think for now I am going to continue using LDAP as we are and re-evaluate adding Kerberos later or at most selectively enable it for our admin users in the short term. :) Regards, -Alan On Wed, Sep 14, 2011 at 3:22 PM, Simo Sorce s...@redhat.com wrote: On Wed, 2011-09-14 at 15:19 -0400, Rob Crittenden wrote: Simo Sorce wrote: On Wed, 2011-09-14 at 15:08 -0400, Simo Sorce wrote: On Wed, 2011-09-14 at 11:36 -0400, Dmitri Pal wrote: Can Freeipa accommodate a mufti-tennant environment? i.e. I work for a managed service provider that currently uses LDAP for authentication for both our users and our customer's users. But Customer A cannot see Customer B's data due to access control on our directory. Each customer has at least one LDAP service account in their container in the tree that can only view that customer's container and my company container. At the moment we do not have the ability to move accounts into sub containers. It is a feature we may want to implement in future, but we kept the tree intentionally flat to avoid misuse we've seen as quite common in products like AD. Would we have to do something like create realms for each customer? Then configure trusts from customer realm to ours? EXAMPLE.COM - our realm CUSTOMERA.EXAMPLE.COM - customer a realm ... so on This may work onve ipa v3 is out. Building multiple realms (in multiple servers/VMs) is possible but trust relationship management is not fully backed in yet. What about data within the directory? Currently our DIT is like: o=MyCompany,dc=example,dc=com o=CustomerA,dc=excample,dc=com If you create multiple realms you'll have to do it with multiple servers with current IPA. Would seperating by realms automatically divide that up? What about would Customer A be able to see any Customer B users using multiple realms alone or would we have to take additional precautions? In general ACIs can be used to limit who sees what. It may be possible to use the current flat view on the server and constrain access to specific users/groups using a bit of custom schema in order to label entries, and custom ACIs. Of course you would want to turn off anonymous access to the directory and encrypt all traffic with SSL or GSSAPI at that point. Replying to myself, custom schema may not be necessary. It may be possible to use just ACIs and non-posix groups together w/o adding additional schema, that would make the problem simpler, although ACIs need to be built carefully not to cripple the admins view. Simo. The management framework only supports a single realm as well, even if you could manage to insert the data. The ACIs solution would work with a single-realm model ... except that it also means each customer needs to do very careful access control when using kerberos for now, as we do not have a way to constrain which users can get tickets for which services in the same REALM. This is something we want to introduce in v3.0 anyways for various reasons. So going forward, segmentation of users should become simpler. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
