[Freeipa-users] External Collaboration Domains

[Alexander Bokovoy]

On Tue, 25 Mar 2014, Nordgren, Bryce L -FS wrote:
>
>>Collaboration can be in different ways. It all depends on the use case. It can be OpenID, SAML, Kerberos, etc. There are different technologies and they suit better different use cases.
>
>>Can you please share under what circumstances such "inversion" would actually be needed?
>
>Console logins in a domain specifically created for collaboration with
>external entities. Expect that there is a one-way trust from the
>organization's "internal" domain (providing users) to the collaboration
>domain (providing services). The collaboration domain would host
>services and devices necessary for the execution of various projects.
>Project members are NOT from a small set of closely knit organizations,
>where it is feasible to establish cross domain trusts. As this is a
>large organization, many projects are starting, in-progress, and ending
>at all times. New projects do not necessarily require trusts to the
>same set of organizations as existing or finishing projects. Services
>may be web services, shared filesystems, standalone processing
>machines, and high performance computing assets. The services have
>service or host principals in the collaboration domain's domain
>controller. From an IT perspective, this is similar to interacting with
>customers, except the customer!  s deploy and/or access stuff on your
>network.
>
>Much of the horsepower in this domain will probably be some variant of
>Linux. There are instances of high-horsepower Windows and Mac
>devices/clusters, but they are not common.  Source code control, issue
>trackers, networked filesystems, datafiles, and metadata development
>webapps have a presence here. Esoteric scientific equipment may be
>connected to the network, but will probably not be Kerberized (i.e.,
>Gas Chromatograph Mass Spectrometer). Terminals may be Mac, Windows,
>Linux, Android or iOS and may belong to guests. This is just in my
>building in Montana. Nationwide the situation is likely to be more
>chaotic. The big reason everything is here: it either violates
>enterprise policy or needs to be accessible by external users (which
>violates enterprise policy).
to sum up above, you'd need POSIX identities for users and groups coming
from nowhere to be created and associated with their external
credentials.

This is not really different from what many web sites do which accept
3rd-party authentication promise but then create own accounts once
you've passed through OAuth2, for example.

So you would have an IPA domain where you would have a portal that
creates users after they successfully authenticated to a third-party you
trust. FreeIPA 4.0 will have support for external RADIUS server
authentication as a token that can be associated with a user. Note that
this user has to be created first but overall this is doable.

However, consequent logins through console would assume you are actually
using your third-party password or two-factor auth directly. This means
no previously issued OAuth2 assurance can be of any help here as you are
not dealing with a browser here that obtained the assurance. May be at
this point it would make sense to actually switch the user to some
generated password or 2FA unique to the collaboration domain?


>If such a domain were to exclusively contain web services, one wouldn't
>need  a domain controller at all. Something like gluu or openam would
>suffice. But I need to share files and support console access in
>addition to web access. Using the same credentials. Which I don't want
>to manage.
For web services exclusively, a scheme with external RADIUS provided
token is OK.

>If the KDC is bundled as part of a larger directory solution like
>IPA/AD, then some "extra overhead" (SID/UID) needs to be synthesized
>for use within the domain when the identity is first encountered. This
>is not more work than offering your realm's services to Kerberos users
>(from IPA? AD? Kerberos+LDAP? Just Kerberos?) who arrive from a foreign
>realm (via PKINIT or trust) when you have no way to access this
>non-kerberos information in the user's home realm. Letting the local
>domain controller do it guarantees it's harmonized within the realm.
See above.

>There has to be a standardized method for encoding these foreign user
>principal names and realms. You want subsequent logins to use the same
>principal (and same SID/UID). You also want the principal name and
>realm to be the same no matter how it shows up in your realm (e.g., via
>direct login or via a trust). This may involve the creation of zero or
>more new Kerberos nametypes.
I don't think you really need to invent something here. Authenticate
over some third-party source at sign-up, ask user to accept terms of
use, create IPA user for the user, associate external token with the IPA
user based on already obtained OAuth2 token user gave you when signed
up. Keep external identity in the IPA user account:

ipa user-add <user> --radius=<radiusproxy-name> \
                     --radius-username=<external-name> \
                     --user-auth-type={password,radius}

then set password that user will be using for non-web services. It would
be usable for web services too, though, but that is a detail.

On consequent logons to the web service use the negotiated OAuth2 token
to authenticate to the RADIUS server that will use it to communicate
with a third-party.


>Maybe this could be done by adding an external login page to IPA's
>management web interface, which coordinates the necessary actions
>between the HTTP authentication workflow, LDAP, the DogTag CA, PKINIT
>to the KDC, and which returns the TGT to the browser (or displays an
>error). There are many pieces involved, but most are already gathered
>together. Aside from browser support of this mechanism, this does not
>seem like an overly invasive solution to any particular component.
What we see is that increasingly people want to hide IPA web UI and
integrate such functionality in their own tools/interfaces. So we can
provide something like that but it would be hardly usable to others due
to difference in the technologies used to build web UIs.

Having an article that shows how to do it with one of possible tools
would be good, yes.

>In any case, IPA would need to synthesize "extra" data (UID/SID) for
>this PKINIT/foreign-user connection, as it should be doing now for all
>non-anonymous PKINIT connections. :) May I ask how IPA handles this
>case now? Googling shows me that there is PKINIT support, but I can't
>tell whether this includes setting user attributes...
See above, read http://www.freeipa.org/page/V3/OTP

-- 
/ Alexander Bokovoy