[Freeipa-users] External Collaboration Domains

[Alexander Bokovoy]

On Sun, 30 Mar 2014, Nordgren, Bryce L -FS wrote:
>Hey guys,
>
>Back again. Thanks for your responses so far.
>
>OTP is interesting, but requires that an account be created in the
>local domain, which is kind of opposed to the notion of federated
>identities.
>
>Ipsilon is also interesting, from its description as a gateway to
>non-Kerberos identitiy providers. I have not located much information
>about it, though.
>
>I've taken a couple of days to put together an RFE with three use cases
>and tons of pictures. It locally maintains user attributes in LDAP
>without creating a corresponding authentication principal in Kerberos.
>It offers a little more flexibility for integrating AD users to an IPA
>managed POSIX realm without conflicting with the existing method. It
>also makes possible the management of inter-organizational cross realm
>operation using PKINIT. Finally, it describes an interface between the
>IPA server and Ipsilon (or any identity gateway), and a mechanism by
>which Ipsilon may acquire TGTs for the local realm on behalf of clients
>who authenticate via remote, non-Kerberos identity providers. This last
>workflow is generic and supports methods other than a web-browser.
>
>Please take a look and help me improve it. Also pls educate me out of
>any mistakes you detect. Part of the reason for doing this is for me to
>make sure I learned Kerberos concepts correctly.
>
> http://www.freeipa.org/page/External_Users_in_IPA
Thanks for the writeup. 

I think it does not really differ from what I described, conceptually.
It is, however, requiring much more work than what I described.

FreeIPA has flat LDAP DIT. Adding support for separate OUs is in itself
a non-trivial task.

Provisioning of an external user's account in LDAP in a separate OU
does not change anything from what we already would do for creating
accounts for external users on the fly, in standard users tree, and
putting them into a specific group set.

However, provisioning users in a separate OU would also mean changing
many of other functional modules to add awareness of those OUs. HBAC,
for example, needs changes on both server and client (SSSD) side. Client
side changes to properly recognize DNs of external users from a
separate OU when resolving HBAC rules will need to be distributed to all
IPA clients, including those where upgrade of the software is not
possible due to a customer constraints. Re-using existing mechanisms has
own advantages of not changing the client side.

PKINIT use in Kerberos is a big issue. Right now certificates produced
by FreeIPA do not include special extension that Kerberos KDC requires
to have PKINIT working. We have a ticket to solve this but it depends on
few items missing in FreeIPA, Dogtag, and nss. Solving it is required
for full OTP use, so we might gain this feature sooner or later.

I would generally not recommend both diminishing or relying too much on
existing RFCs for certain LDAP storage schema proposals, specifically
for Kerberos. These have little value outside of specific Kerberos KDC
backend utilizing them. We have already our own schema, specific enough
for FreeIPA and we are going to continue using it, regardless how
'expired' or new certain RFCs. There is simply no universal agreement
here and no need for it, actually.

What's reasonable and can be relatively easily pulled in from your
proposal is a mechanism to get users automatically provisioned in
FreeIPA based on their cross realm identities. For example, for cross
realm trust with AD we have means to selectively block certain SIDs from
being imported from the AD. The rest is recognized and accepted but no
local external groups created for them. We simply can automate creating
the groups on login attempt if SIDs involved aren't blocked. This
automation should solve majority of administrative load.

-- 
/ Alexander Bokovoy