<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 12/15/2011 09:24 AM, Adam Young wrote:
<blockquote cite="mid:4EEA2D54.5000306@redhat.com" type="cite">
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
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.<br>
<br>
<meta http-equiv="CONTENT-TYPE" content="text/html;
charset=ISO-8859-1">
<title></title>
<meta name="GENERATOR" content="LibreOffice 3.4 (Unix)">
<style type="text/css">
<!--
@page { margin: 0.79in }
P { margin-bottom: 0.08in }
H3 { margin-bottom: 0.08in }
H3.western { font-family: "Liberation Sans", sans-serif }
H3.cjk { font-family: "WenQuanYi Zen Hei" }
H3.ctl { font-family: "Lohit Devanagari" }
H4 { margin-bottom: 0.08in }
H4.western { font-family: "Liberation Sans", sans-serif; font-size: 11pt; font-style: italic }
H4.cjk { font-family: "WenQuanYi Zen Hei"; font-size: 11pt; font-style: italic }
H4.ctl { font-family: "Lohit Devanagari"; font-size: 11pt; font-style: italic }
-->
</style>Description<br>
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.<br>
<br>
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.<br>
IPA Status<br>
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.<br>
<br>
<br>
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.<br>
<br>
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.<br>
Required Changes<br>
These are the changes necessary to the FreeIPA server to support
a cloud deployment and multi-tenancy.<br>
Directory Server<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
When updating IPA, schema changes need to be applied to each of
the the tenant trees.<br>
API<br>
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. <br>
</blockquote>
Some configuration changes will need to be made around a number of
the Directory Server plug-ins with regards to scope. We will likely
need separate configuration entries to restrict the plug-ins to each
tenant subtree. This includes the following plug-ins (and maybe
others as well):<br>
<br>
- memberOf<br>
- DNA<br>
- Managed Entries<br>
- Auto-Membership<br>
- Attribute Uniqueness<br>
<br>
<blockquote cite="mid:4EEA2D54.5000306@redhat.com" type="cite"> <br>
BaseLDAP plugin<br>
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.<br>
Kerberos<br>
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.<br>
<br>
DNS<br>
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.<br>
<br>
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.<br>
<br>
CA<br>
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.<br>
IPA-CLIENT<br>
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.<br>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Freeipa-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Freeipa-devel@redhat.com">Freeipa-devel@redhat.com</a>
<a class="moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/freeipa-devel">https://www.redhat.com/mailman/listinfo/freeipa-devel</a></pre>
</blockquote>
<br>
</body>
</html>