>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).

System administration responsibilities in this collaboration domain are largely 
distributed to the system owners and not centralized in the IT organization. 
There is no or little commonality in purpose, intent, authorization roles, 
characteristics, or business case for the systems, inter-project. Similarities 
may exist between multiple resources associated with a common project, or 
projects with a common theme. Many semi-autonomous fiefdoms ensue, most with a 
limited lifetime, composed of people none of whom want to manage user accounts, 
and none of whom want new passwords. Few want to monkey with security at all.

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.

>Your Google account does not use Kerberos that means that your password goes 
>over the wire. The whole point of Kerberos that password does not go the wire.

Me thinks your flow is reversed. Posit an HTTP version of the AS exchange with 
the KDC, where users who are not present in the domain controller obtain TGTs 
for the local domain via their browser. The user doesn't provide a password to 
the KDC, nor does it provide a signed public key, but they do demonstrate they 
are recognized by a foreign IdP via a browser workflow defined by (SAML|OpenID 
Connect|OpenID|other). Conceptually, this is no different than PKINIT, in that 
the KDC puts its trust in (a presumably configurable) list of identity 
providers utilizing a varied patchwork of HTTP identity technologies. When the 
KDC's "external identity" webpage is satisfied that the remote IdP is happy 
with the user's  identity, it can return a TGT to the browser using a TBD 
encoding which the browser stores in the local ticket cache. The user in 
control of the browser session can then ssh into a machine via gssapi, or mount 
an NFSv4 filesystem, or connect to any of the realm's webservic!
 es using gssapi/spnego. Of course, the web services could also allow the 
native use of the foreign identity technologies.

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 

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.

This doesn't send passwords over the wire for users defined in the KDC. It also 
doesn't stop the alien technologies (non-Kerberos) from sending their own 
passwords over the wire. However, it does drastically reduce the number of 
accounts you have to create and manage in an external/collaboration domain. 
Your collaborators are happier because they don't have another password. It 
also gives you a central point of control over just exactly which foreign IdPs 
are accepted. The user's identities are exactly as trustworthy as they are in 
their native web context (no more no less). The many and varied machines in 
your domain don't need to worry about how to interact with a plethora of 
identity technologies. They just need to be kerberized and defer all 
authentication worries to the collaboration domain's KDC.

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.

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...


This electronic message contains information generated by the USDA solely for 
the intended recipients. Any unauthorized interception of this message or the 
use or disclosure of the information it contains may violate the law and 
subject the violator to civil or criminal penalties. If you believe you have 
received this message in error, please notify the sender and delete the email 

Freeipa-users mailing list

Reply via email to