Sorry for the delayed reply. This is "other duties as assigned" and the day job 
got in the way. :) However, the computer is busy running fits to data for the 
next day or so. My electronic master is thus distracted.

> >> Wow!
> >> First of all thanks for a nice pictures and sharing your ideas.
> >> A lot of work and though put into it.

You're welcome. Glad you liked it.

> >> Let me just point couple things:
> >> 1) It looks like the whole idea is about creating entries for
> >> external users on the server when external user authenticates via
> >> KDC. But don't we already lookup cache these users in a local SSSD
> >> cache and expose via the compat tree for legacy clients?
> >> AFAIU the purpose is to be able to create local groups for the
> >> external users. May be we can do something and use compat tree DNs
> >> for external users?
> >> In general it is better to distill the problem we are trying to
> >> solve: did I get it right?

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.

Also, if foreign users are going to participate in file sharing within the 
local realm, their UID/GIDs need to be synched among all endpoints in this 
realm. In general, since users can be coming in from many domains which do not 
coordinate such assignments among themselves, these IDs need to be harmonized. 
Furthermore, if users "enter" the local realm via Ipsilon because they're using 
OpenID or SAML, their point of origin may not maintain that type of information 
at all. The entity which handles this needs to have the responsibility for 
doing so on a realm wide basis.

> >> 2) I think PKINIT and related part of the proposal is not something
> >> that we would do.
> >> Instead of PKI based Ipsilon would use GSS proxy that implements
> >> s4u2proxy + s4u2self to acquire a ticket on user behalf.
> >> This functionality already exists, so there is no new code need.

As I understand it, you're suggesting that s4u2self is well suited to address 
use case three, and it has the added bonus of being already implemented. I 
don't have time to update the figures for that section now, but I'll put it on 
the list.  To ensure I understand, the proposed flow is: Ipsilon obtains a 
service ticket to itself on behalf of the remote user via s4u2self. It then 
uses this service ticket in an s4u2proxy request to obtain a service ticket for 
krbtgt/LOCAL.REALM, which it then returns to the user. Presumably the only 
change in proposed auditing would be to monitor s4u2user exchanges for "first 
encounters" with foreign principals.

PKINIT is involved in two use cases. Use case two allows native Kerberos cross 
realm operation without requiring the close coordination of admins from 
different domains. In addition, PKINIT is the gateway to interoperating with 
the grid security infrastructure (GSI) and federations of high-end computing 
facilities. S4u2self really doesn't address use case two.

Presumably, s4u2self will be limited on the IPA side to a small list of 
whitelisted services such as Ipsilon. Failure to do so could be catastrophic. :)

> >> 3) The case when you send TGT back to the client from Ipsilon that
> >> authenticated user and acquired TGT on his behalf is an interesting
> >> one. The intent for client to later use SSH is understandable though
> >> hard to achieve. Currently there is no mechanism for Ipsilon or
> >> Ipsilon like gateways to return the TGT for a user and pass it to
> >> client browser. There is also no way a browser can save this TGT in
> >> the cache.

The browser has access to the cache, else it couldn't gssapi/spnego  to 
kerberized websites. I think it's more accurate to say that there is not 
currently a widely supported mechanism which supports retrieving a Kerberos tgt 
over nonstandard channels.

Fair enough. But use case 3 is not currently widely supported either. 
Supporting it dramatically reduces the administrative burden on the local realm 
admins (they don't have to create and maintain accounts for foreign users, or 
separately negotiate with all the realm admins of each cooperating 
organization). Supporting use case three also creates a collaborative workspace 
featuring console logins and secure filesharing while maintaining the ease of 
identity administration typically associated with federated web-based 

While not widely supported, there have been some suggestions related to 
nonstandard tgt delivery.

* KDC Proxy -- / MS-KKDCP

In addition, use case three also requires coming up with a unique map of users 
from non-Kerberos origins (OpenID/SAML/etc). If the solution is to be 
interoperable across realms, this mapping needs to be consistent across realms.

Use case three is kind of the holy grail. If it were easy and quick, everyone 
would be doing it. I think the key is to identify capabilities such as: 1] 
auditing specific kinds of exchanges with the KDC to identify first contact 
with a foreign identity; and 2] synthesizing and harmonizing information about 
foreign identities. With these capabilities in place supporting native Kerberos 
cross-realm operation, it puts us in a better position to later support foreign 
identities supplied by a non-Kerberos provider.

The bottom line for use case three is that much of the hard stuff can be dumped 
onto Ipsilon. IPA shouldn't be bothered with authenticating using foreign 
technologies, nor should it need to map user identities. IPA is Kerberos based 
and should deal with Kerberos cname/crealm string pairs. It just needs to 
identify cname/crealms it hasn't seen before and supply enough "extra" 
information to make the services/hosts in the local realm happy.

> >> Bottom line:
> >> Let us focus on the problem we are trying to solve here. Keep in mind
> >> that we have not started designing IPA to IPA trusts and Kerberos to
> >> IPA trusts. It might very well be that we would need to create some
> >> external entries for those trusts so IMO looking into these trust
> >> scenarios would reveal where our AD integration approach lacks
> >> external info and needs to be extended. If we want to solve the high
> >> level problem of trusts in general we need to build those specific
> >> flows and see what data is not in ldap and we can get it there. A
> >> simple mental exercise  suggests that we would need something for
> >> grouping of the identities coming from a vanilla trusted Kerberos
> >> domain. May be this is something we should drill down as a next step?
> > Now we have this tracked with the ticket
> >

I agree. :) Further, I believe that if you offload the task of interacting with 
"alien authentication technologies" to something like Ipsilon, all foreign 
identities from any source will appear to IPA as if they are coming from a 
vanilla trusted Kerberos domain. Ipsilon does the mapping.

> > Bryce, please continue expanding on your potential use cases using the
> > wiki page you've created. I'm not sure we are even close to start
> > implementing this but gathering the information is a first step.

How do you think I should include interaction with grid security 
infrastructure? Technically, it's another use of PKINIT, so I'm not thinking it 
gets its own section. Maybe a paragraph in the existing use case 2? On the 
other hand, it's a whole separate world of identities.

> > I think Dmitri has some valid questions above that might be good to
> > answer through your wiki page.
> >
> And may be we can start smaller. Can we have a concise definition of the
> speific problem we are trying to solve here.
> May be there are different ways to solve it other than auto creating records.

How about the opening of this email? " 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."


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