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