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
_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
