Add support for FreeIPA ID viewsidviews

FreeIPA ID views allow to override POSIX attributes for certain
users and groups.

A support is added to allow using specific ID view when serving
compatibility tree. Each user or group entry which has an override
in the view is amended with the overridden values from the view
before served out to the LDAP client.

A view to use is specified as a part of base DN:

	cn=<view>,cn=views,cn=compat,$SUFFIX

where cn=compat,$SUFFIX is the original compatibility tree base DN.

Each entry, when served through the view, gets new DN rewritten to
specify the view. Additionally, if override in the view changes
uid (for users) or cn (for groups) attribute, the entry's RDN is changed
accordingly.

For groups memberUid attribute is modified as well in case there is an override
in the view that changes uid value of that member.

FreeIPA ID views support overrides for users of trusted Active Directory domains.
In case of a trusted AD domain's user or group is returned via compatibility tree,
view overrides are applied in two stages:
  1. SSSD applies default view for AD users
  2. slapi-nis applies explicitly specified (host-specific) view
     on top of the entry returned by SSSD

Thus, slapi-nis does not need to apply default view for AD users and if there are
no host-specific views in use, there is no need to specify a view in the base DN,
making overhead of a default view for AD users lower.

1 files changed, 93 insertions, 0 deletions

diff --git a/doc/ipa/sch-ipa.txt b/doc/ipa/sch-ipa.txt
index b5a585b..f560580 100644
--- a/doc/ipa/sch-ipa.txt
+++ b/doc/ipa/sch-ipa.txt
@@ -87,3 +87,96 @@ on  IPA masters.
 
 As 'system-auth' PAM service is not used directly by any other application, it
 is safe to use it for trusted domain users via compatibility path.
+
+== Support for ID views ==
+
+When FreeIPA 4.1 is in use, Schema compatibility plugin can be configured to
+override POSIX attributes according to an identity view (ID View) which
+contains overrides for users and groups.
+
+The overrides are managed by FreeIPA separately for users and groups:
+
+* management of ID views:
+  ipa idview-add 'my view'
+
+* management of an override for a user:
+  ipa idoverrideuser-add 'my view' auser --login=foo --shell=/bin/ksh \
+                                         --homedir=/home/foo --uid=12345
+
+* management of an override for a group:
+  ipa idoverridegroup-add 'my view' agroup --group-name=bgroup --gid=54321
+
+FreeIPA transparently supports overrides for users and groups from trusted AD
+domains.  This means that for trusted domains, IPA doesn't require to place
+POSIX attributes in Active Directory. Instead, a global ID view named 'Default
+Trust View' is used to contain POSIX attributes for existing AD users.
+Additionally, specialized ID views can be added on top of the 'Default Trust
+View' and then assigned to specific hosts.
+
+Schema compatibility plugin does support ID overrides from a single view. The
+feature is designed to allow host-specific ID view, where the view is specified
+through the search base.
+
+For native IPA users default POSIX attributes are stored natively, thus only a
+host-specific ID view is applied, if any. For trusted AD users 'Default Trust
+View' ID view is applied automatically by SSSD running on the IPA master, thus
+Schema compatibility plugin only applies a host-specific ID view, if specified.
+
+In FreeIPA Schema compatibility is configured to serve entries through the
+host-specific ID view with base DN of cn=<ID view>,cn=views,cn=compat,$SUFFIX.
+
+=== ID views implementation ===
+Detailed design of ID views in FreeIPA can be seen here:
+http://www.freeipa.org/page/V4/Migrating_existing_environments_to_Trust
+
+In Schema compatibility plugin support for ID views is done on top of existing
+map cache. It is expected that there are less overrides than non-overridden
+entries for IPA users and groups. For trusted AD users POSIX attributes from
+'Default Trust View' are applied by SSSD on IPA master. Thus, if there are no
+host-specific overrides, trusted AD users treated by Schema compatibility
+plugin as before -- as entries which content comes from nssswitch API.
+
+This approach allows to only keep original entry in the memory and apply
+host-specific override only at the time when entry with explicitly requested ID
+view is returned as part of a search result.
+
+In order to map original entry to an override, FreeIPA configuration for Schema
+compatibility plugin adds ipaAnchorUUID attribute and ipaOverrideTarget object
+class to every generated entry. ipaAnchorUUID is based on ipaUniqueID for IPA
+objects and on SID for trusted AD objects:
+
+* ipaAnchorUUID=:IPA:<domain>:<ipaUniqueID> for IPA object (user, group)_
+
+* ipaAnchorUUID=:SID:<SID> for trusted AD user or group
+
+For ID overrides FreeIPA maintains ipaAnchorUUID with the same value so that an
+override can be found by simple matching of the ipaAnchorUUID attribute's
+value. FreeIPA also stores original uid value for user objects in ID override
+as ipaOriginalUid attribute, to allow mapping back memberUid values for groups.
+
+When a query request comes, the view in the base DN is detected and remembered.
+Base DN is rewritten to exclude the cn=<ID view>,cn=views so that a normal
+search can be performed against cached entries. Additionally, search filter is
+analyzed to replace references to rewritten uid (for user) and cn (for group)
+attributes by references to the original objects. The references come from the
+ID view overrides, if they exist.
+
+Once search results are gathered for the map, they are processed in order to
+apply an override.  For users entry attributes overridden with the values from
+an override. For groups additional processing is performed on values of
+memberUid attribute.
+
+As opposed to member attribute, memberUid attribute contains only values of uid
+attribute of the original member entry.  Given that an ID override may redefine
+uid value, corresponding memberUid value of a group needs to be rewritten to
+include redefined uid value. In order to do that, original memberUid value is
+compared with ipaOriginalUid attribute's value to find an override
+corresponding to the original user object. If such override is detected, memberUid
+value is replaced by the uid value of the override.
+
+When attributes of the entry are processed and optionally amended with overridden
+values, DN of the entry is rewritten as well, to reflect the fact that entry is
+served through the view.
+
+For all returned entries ipaAnchorUUID attribute and ipaOverrideTarget objectclass
+are removed. Resulting entry is sent to the client.