[Freeipa-devel] Multitenancy in FreeIPA

[Adam Young]

This is a first attempt to write up an approach for multitenancy in 
IPA.  Please provide feedback.  I've attached the document as well,  as 
that should be easier to read.

Description
Multi-tenancy  is an aspect of Identity Management (IdM) where multiple 
parties use the same resource without learn any information about each 
other.   The example is two rival companies who both operate servers 
hosted in a public cloud.  Neither company should be aware of the 
existance of the other users presence in the web  using, and they 
definitely should not be able to enumerate either the users or the hosts 
of the other company  due to information leaks inside the cloud services.

The entities stored under each tenant have a relatively high likelihood 
of reusing the same names.  User names and group names are often have a 
high number of names that are commonly used.  For example,  both 
companies might have someone with the user name of asmith  and a group 
named developers.  However,  in the first company,  asmith has a UID of 
512  and developers has a  GID of 2100,  but in the other company  
asmith has a UID of 87687 and developers has a  GID of 6332.  Both need 
to exist in the IdM server  and be distinguishable from the other.
IPA Status
IPA currently has a completely flat data model.  All data is store in 
two subtrees:  one for the IPA  user and host database,  and one for the 
PKI CA. The kerberos server would only server out tickets for a single 
domain.  The Directory server has the vast majority of its data open 
read only available to anonymous binds.  The user Admin has full control 
over the entire set of entites in the system.


IPA  stores the data it manages inside a Directory Server (389) instance 
in a subtree that, by default, mirrors the hostname of the server.  Thus 
the server ipa.example.com would store in the subtree 
cn=ipa,cn=example,cn=com.  The layout of this subtree will be referred 
to as the current schema.  The instance of the subtree itself will be 
referred to as the current baseDN.

In addition,  each IPA server manages a Kerberos Realm.  By default   
the name of the realm matches the domain name,  but in all capitals.  
The zone example.com  would have a corresponding realm EXAMPLE.COM.
Required Changes
  These are the changes necessary to the FreeIPA server to support a 
cloud deployment and multi-tenancy.
Directory Server
Each tenant in the cloud would get their own subtree.  It would get a 
BaseDN  of the form:cn={TENANT},cn=tenants,$suffix.  This subtree would 
have a copy of the current schema.  The initial  (undeletable) suffix is 
used for the cloud provider.  These subtrees will be referred to as 
tenant trees.

When performing an action in the IPA server, the user is identified by  
their principal,  which contains the Kerberos Realm name.  This can be 
used to distinguish which  domain,  and by extension, which subtree,  
the action should use for data.  Operations are limited to the current 
zone.  Cloud administrators will need the ability to override this in 
order to perform maintenance operations on the tenants.

The directory will no longer be world readable.  Instead,  ACIs will 
limit the users ability to read only the subtree in which they are 
enrolled.  LDAP operations will require an authenticated bind.

When updating IPA, schema changes need to be applied to each of the the 
tenant trees.
API
Each of the RPCs need to allow an optional parameter  tenant.  Members 
of the original domain with an approapriate Permission will be able to 
perform operations inside the tenant specified.

BaseLDAP plugin
Instead of just reading the BaseDN out of the configuration file,  the 
base DN needs to be calculated based on the Kerberos principal  of the 
calling user.  This value should be cached in the WSGI application so 
that it does not always require multiple round trips to the LDAP server.
Kerberos
Each tenant would get its own Kerberos Realm,  but each would trust the 
Cloud Provider's realm.  The httpd/mod_auth_kerberos needs to be capable 
of accepting new realms.  When adding a new tenant,  we might need to 
update krb5.conf on the IPA server to know about the new realm.

DNS
The BIND  DynDB back end code would need to be extended to read zone 
information from multiple subtrees in order to read the DNS entires in 
the tenant trees.

It is also possible to keep the current approach, and then add the 
ability to identify which users and tenants can manage and control DNS 
entries.  The simpler solution is to modify BIND Dyn DB.

CA
We would continue to have only one CA, and have IPA submit all 
Certificate requests as a single Agent.  The IPA server will ensure that 
a user can only request certificates for entities within their own subtree.
IPA-CLIENT
When enrolling a host,  the principal used to authenticate with the IPA 
server will determine which subtree will hold  host.  This involves 
changing the LDAP configuration information in the following client 
components:  SSSD, nss_ldap, and Kerberos.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20111215/42bda022/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: multitenancy-0.0.0.odt
Type: application/vnd.oasis.opendocument.text
Size: 16213 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20111215/42bda022/attachment.odt>