[Freeipa-users] External Collaboration Domains

[Dmitri Pal]

On 04/08/2014 12:50 PM, Nordgren, Bryce L -FS wrote:
> 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.

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.


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

But they already are at least in the AD case! Same can be applied to 
other cases.


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

You might be right here but we yet to understand whether there are 
actually the flows that would require creation of such users and which 
part would be in charge of doing them. It might be very well that 
Ipsilon will be seeing new external users first and will be creating 
them as needed based on the policies. I actually suspect that this would 
be the case. But we are not there yet even as a use case.

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

Yes so far

> which it then returns to the user.

This part is a gray area. I do not think protocol allows for it.
But I am still not sure it is needed.

Let us say we have an application. User U presents a credential X to the 
application A. Application needs to perform an operation against 
application B on behalf of the user. It will do a call using GSS API. 
GSS API will use GSS proxy (already available in Fedora and RHEL7). GSS 
Proxy is already capable of the s4u2self + s4u2proxy it can do it behind 
the scenes and provide everything needs for the connection from A to B 
be authenticated using user's identity.

This is the direction we have been going and this is the area we are 
expanding on.

>   Presumably the only change in proposed auditing would be to monitor s4u2user exchanges for "first encounters" with foreign principals.

I am still not buying into the whole idea that intercepting the cross 
realm kerberos traffic is the right step to synthesize remote users.
For AD integration we do not need that because the external groups can 
be created when you define HBAC and resolved at runtime using info from 
the ticket, no need to create user entries.

The same will happen with IPA <-> IPA.
I think it is a good practice not to create user entries for the users 
that you do not control.

For UID and GID if users is from AD we have two options - create UID/GID 
from SID or use it from AD itself by performing a lookup from SSSD client.

We still have a use case that we have not solved.
This is the use case when deployment wants to use UID/GID stored in IPA 
but user coming over the trust. But in this case the user will be 
already created in IPA. This is sort of migration use case from an old 
NIS setups. As new users will be added on AD side they will not need 
POSIX attributes in IdM since the SID to UID/GID conversion will kick 
in. So even in this case automatic creation of entries does not seem to 
be needed.

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

There are already ways to control it in IPA they are just not exposed in 
UI or CLI

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

...and _saving_ it on the client system for other components to use.

The key part is that browser can read the cache but it can't write to it.
There however an idea tham may be browsers can be taught to use IEKERB. 
But this would be quire an effort to make browsers do that.
If they are taught then the exchange would happen behind the scenes but 
kinit will be sort of integrated into browser and run on the browser side.

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

Existing trusts already support that. Please watch the videos that we 
prepare for summit next week once they are published.
It will give you some hints.

>
> While not widely supported, there have been some suggestions related to nonstandard tgt delivery.
>
> * IAKERB -- http://tools.ietf.org/html/draft-ietf-kitten-iakerb-01
> * KDC Proxy -- http://www.freeipa.org/page/KDC_Proxy / MS-KKDCP http://msdn.microsoft.com/en-us/library/hh553774.aspx
>
> 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.

May be.
So can we split the proposal into smaller parts?

May be have a high level page that describes what we want to accomplish 
and then take it from there?
So far I see that creation of the external users might be needed only if 
the users are coming from non kerberos sources.


>
>>>> 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
>>> https://fedorahosted.org/freeipa/ticket/4287
> 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.

And may be creation in needed...

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

The page now is too long and complex. It is hard to follow it touches 
many use cases and flow can can be discussed independently.
I agree that this needs to be sorted out but let us build it from a 
smaller blocks and get people on board.
So far you lost most of the audience :-)
Let us start small - use cases and agree on them. Then we can take then 
one at a time and see where the overlaps and common patterns.
It is great that you already have an uber picture in mind but it is hard 
to align an uber picture with pictures others have. If you build it 
gradually you also build agreement and buy-in that this is what and how 
we age going to do long term as a community.
Keep in mind that some of the areas that you are concerned about we have 
not though about much. We acknowledged their existence but they are a 
bit too far in future for it to be practical to talk about them yet.


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

Sure however I would start with a wiki page that would create a table:

Remote/Local                   NFS       Web application     SSH     Something else
Trusted AD                    <-------- Solved with trusts ----------->
Trusted IdM                   <--------Will be solved with trusts ---->
External not Kerberos user    ???          ???                ???
...


So what we really trying to do is to define how users that do not have Kerberos identity in the local
realm and not authenticating Kerberos would be able to access resources.
This is a fine goal so let us create sub pages in places of ??? and see what makes sense and what not.
IMO it would be easier to digest this way.

Agree?





>
> Bryce

Thanks for being patient with us it is really appreciated.
We are glad that you are pushing things forward, we just might be a bit 
slow to grasp your ideas :-)

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


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.