[Freeipa-users] External Collaboration Domains

[Dmitri Pal]

On 03/25/2014 03:12 AM, Alexander Bokovoy wrote:
> 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
>
In addition to what Alexander said I think what would be possible soon 
is to use Ipsilon (our IdP project) gateway to authenticate using one 
authentication method and then translate the authentication into some 
other token i.e. SAML, Kerberos or something else. We are working on this.



-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/