[Freeipa-users] External Collaboration Domains

[Nordgren, Bryce L -FS]

> > Close. The problem is to expose kerberized services in the local realm to
> users holding foreign credentials, supporting SSO wherever possible. This
> includes file sharing via NFS, kerberized web apps, ssh logins, and anything
> else the local realm has to offer. SSSD can handle ssh logins (if one considers
> it "handled" to transmit the password over the wire and abandon SSO), but
> cannot handle the former two.
>
> This is already handled with the trusts feature with AD. It is handled by SSO
> and using Kerberos ticket renegotiation between two domains.
> The similar approach would work for IPA to IPA and IPA to Kerberos. In the
> IPA to IPA case we will have authorization data in the ticket that would help
> with this.
> I am sorry I fail to see a driver and use case here. But may be I am missing
> something obvious.

Trusts are only feasible between tightly coordinated realms and with the involvement of admins. The use case is a collaboration realm, where users (not admins) drive the connections between realms. This precipitates everything in the proposal. If the user is coming from an AD realm, there may not be a trust, and it may be inappropriate to have an admin form one if there are only three or four users binding the two realms together. The AD realm may be behind the institutional firewall and the KDC inaccessible, making PKINIT a good choice. Perhaps kx509 certificates are not available from the home realm, making OpenID or SAML a good choice.

A theme in your previous message was that some use case is already covered because the admin can explicitly take some action to handle it, and each instance (each new trust) needs to be individually created and then managed. The point of this RFE is that the admin can set  up a realm which responds to how users travel from realm to realm, offering both flexibility for the manner in which users authenticate and consistency for the services offered by the realm.

It's a different mindset that makes the use case invisible. :)

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.