[Freeipa-users] External Collaboration Domains

[Dmitri Pal]

On 04/11/2014 08:47 PM, Nordgren, Bryce L -FS wrote:
>> There is a groups pf people that belong to different organizations, for
>> example universities that launch a project together. They have the identities
>> in their own home organization (domains). There is a "hosting" organization
>> that some of the members of the group might belong to. Jointly all the users
>> want to be able to access the systems that belong to the project, this
>> includes login into the systems accessing file shares and web applications that
>> constitute the joint project. They also want to be able to SSO as much as
>> possible without creating additional identities and having a separate
>> password. The home organization in this case would have trust relations with
>> the hosting organization.
>> The goal is to make it possible for the home organization to understand
>> external identities accessing resources on the file system level thus POSIX
>> attributes need to be generated, assigned and managed for those users.
>>
>>
>> Does it sound about right? It this the problem we are solving?
> Perfect. I'll make a new wiki page with that text and pictures tomorrow. :)
>
>
>>> Collaboration is not limited to web services. Actually, if you asked me to
>> come up with a real world example where collaboration happened only via
>> web based services, I wouldn't be able to do it.
>>
>> Any Saas application.
>> Google docs for enterprise, SFDC etc.
> True. However, I've never been part of a project where these are all you need. These things do play a role, but aren't comprehensive.
>
>> OK, note taken. I wonder though how common is this scenario/use case.
>> The fact that we hear about it for the first time and having hard time
>> understanding the use case makes me think that it is yet not that common.
>> We would need to see what is the dynamics though and whether the world
>> is moving towards or away from this case becoming a popular one.
>> But assume it is.
> I think it's common at the small scale and typically addressed by individual projects renting dedicated servers at hosting farms. New accounts local to the machines are usually created.
>
> However, over the past ten years I've found that if I've set up "infrastructure", there's no shortage of people who want to leverage it. This tends to cause my tiny solution to scale up and out beyond what I'm willing to support. I suspect that if CIOs were given a notion of what kind of support to offer their users, you may see more demand for something like this.
>
>> OK. Let be paraphrase so that I understand (referring to the use case I
>> mentioned above).
>>
>> Home organization will set a special IPA based domain for every external
>> organization. It will be one way trusted but the hosting organization.
>> This special "collaboration" domain will be the one where the entries are
>> automatically created when external user comes in, right?
> Essentially. I was thinking "home organization" would set up a single IPA based domain with a one-way trust from the internal corporate infra. As you mention, this domain would be where the automatically created external users appear. This single collaboration domain would be the connection point for inter-organizational trusts (vanilla Kerberos/IPA/AD) and would host the identity gateway (Ipsilon).
>
> Is there a need for one domain per organization you want to collaborate with?

Probably not. But this is not significant for the design.

>> b) There is a Kerberos SSO - but then his home domain needs to be
>> trusted by his hosting domain. If it is possible the solution based on
>> trusts exists. But I suspect CIOs do not like it ;-) so it is unlikely
>> would be done in real life.
> Thinking 5 years down the line, if multiple participating organizations had collaboration domains, CIOs may be a little more promiscuous with the vanilla Kerberos trusts between them. Don't rule out Kerberos SSO just yet. :)

We will see when we get there. I am all for it but I see much easier 
ways of the federation via other means in shorter time.

>
>> There is no option to use SAML or OpenID with SSH but to get to the
>> system on the system level you need to SSH.
>> So until SSH supports SAML or similar the whole idea would not fly.
> I wouldn't try to make all domain services aware of all identity technologies.
>
> Option d is use case 3 in the RFE. (Ipsilon obtains TGT for external user and forwards to client). The method of forwarding is what needs to be explored. It seemed to me that the method of getting the ticket from the KDC was fixed on s4u2user / s4u2proxy.

You can get the ticket on the server but you can't deliver it to the 
client side.

>
> However, the RFE is structured such that IPA is prepared to service foreign user requests from an Ipsilon-like HTTP gateway, or an RFC6595-like gssapi/saml acceptor or a RFC6616-like gssapl/openid acceptor. The resolution of the technical approach to use case three is not a blocker.
>
>
>> There is where I see a leap of faith. SAML -> SSH. It is not possible.
>> And I am not sure OpenSSH would be interested to support it. They had
>> hard time supporting Certs.
> No SAML->SSH. Even if it were possible, it would involve configuring every host in the domain individually. Ick.
>
> Browser->Gateway->TGT->Service TKT->SSH. Like normal.

There is no way to deliver TGT to the client. Also there is no TGT on 
the server. TGT can be acquired only using the real credential by 
principal in the initial auth. But this means that principal has a local 
credential (password, cert, token...). But this means it is not an 
external account any more.
Full stop. Sorry.

> GSSAPI/OpenID->GSSAPI acceptor->TGT->Service TKT->SSH. Like normal. or

Does not work. Not possible. You can't get TGT using any kind of service 
ticket.

> GSSAPI/SAML->GSSAPI acceptor->TGT->Service TKT->SSH. Like normal.

See above. This is the flaw in the whole idea.


As I said there are two problems:
a) You can't get TGT using a service ticket
b) If you got a ticker on the server side there is no way to deliver 
this ticket out of band not over kerberos protocol and stick it into the 
client.

Knowing Kerberos community for 6 years I would say the chances for this 
to change are close to 0. I am not sure wheather it is even a good idea 
to change it. Also the change would require a change to all the browsers 
and this is a showstopper in itself.

I think it would be easier to create an SSH client plugin that uses 
existing protocols and flows but it is again a huge task in itself.

>> The account can be created but the local password has to be created too.
>> In this case you are just a local user that can also federate from external.
> Gateway gets ticket using s4u2user / s4u2proxy. Forwards ticket. No password. :)

There is no way to send the ticket back to the client. gateway itself 
would not have access to that ticket too. It can act on behalf of the 
user but not send tickets around.

>
>> IMO this will be possible with the technologies or projects currently
>> being worked on: Ipsilon, apache modules, gss proxy etc.
>> The only part that is not covered is user provisioning. I would think
>> that user provisioning would be a good RFE for Ipsilon.
> External users need a presence in LDAP regardless of their origin (need to participate in groups). Ipsilon will not see external users from Kerberos trusts, including:
> * vanilla Kerberos trusts (all POSIX info needs to be synthesized)
> * AD trust (possibly needing POSIX attributes, possibly needing them remapped to avoid collisions).
> * TBD IPA trusts (possibly need POSIX attributes remapped to avoid collisions).
>
> IPA (specifically, the KDC) is the arbiter of all access to all services in the realm. There is no other single point of monitoring or control.
>
>> To support mapping or local users to the external IdPs we would need
>> Ipsilon to not only create but be able to map external identities to
>> internal identities.
> I believe external identities will need to be mapped to cname/crealm pairs. The mapped crealm will NOT be internal/local. I might be "bnordgren at SAML://idp.usda.gov/geeklogin/" The mapping should be universal so the authenticated user can cross Kerberos trusts without worrying that different realms map the ID differently.
>
>
>> Here is how it might work:
>> [...]
>> I think it makes sense.
> Your proposal requires creating a local account for the external user. If we were to accept the need to do that, would it not be simpler to kerberize the local webapps and the user would spnego/gssapi after kiniting?
Kerberizing something is very hard. We have been doing it for many years 
and the pace is really slow.

>
>>> D] Assuming I can persuade USDA to join the InCommon SAML federation,
>> I'd want user accounts to be autocreated in our collaboration realm based on
>> SAML credentials. We will not be synchronizing IPA external users against the
>> union of all accounts in all IdPs in the federation, so external users must be
>> autocreated.
>>
>> I think I described it above.
>> IMO IdP is the better place for this not the KDC.
> I would be willing to accept this if you can show me how the IdP catches all the external users, not just the ones coming in from SAML or OpenID. I see a crack that my AD account will fall through. :)

The AD accounts are already taken care of but the AD trust feature, 
please setup a trust and see for yourself.

>
>>> E] Users from our own AD should be recognized, but not as a "lump". Each
>> user needs to be able to join groups in the collaboration realm individually.
>> This would require creating a DN for them in LDAP (according to the IdM
>> docs). It's not desirable to replicate all 50000 users from AD to IPA, just the
>> ones who actually connect and use services, so the users who choose to
>> connect must be autocreated.
>>
>> OK. Makes sense. Since I do not expect that the domains would really be
>> accessible over Ldap and Kerberos directly relying on SAML would be the
>> solution to pursue.
> Kerberos is the least common denominator. It's also in the critical path. Nobody gets any services without a ticket. :)

You are assuming what Kerberos can and can't do thus you have design 
that has some fundamental flaws.

>
>> OK. but the kx509 certs from which CA? I assume that we are talking
>> about collaboration CA, so there is really no relation to the home
>> domain and home CA.
> TBD. Configurable. Future. ;)
>
> Note if the realm was configured to accept kx509 from the home CA, it would allow the home domain's AD to stay behind the firewall while allowing me to access the collaboration realm from a partner's facility.
>
>> I think we are on the right path to enable what you are looking for just
>> doing it slightly differently from what you are suggesting.
> I'm patient. And I can deal with workarounds in the near term as long as they lead up to a long term solution. I do want the long term solution not to involve creating/managing local accounts (w/passwords and a local crealm) when a federated account exists. Also, I am not yet convinced that Ipsilon will catch external users coming in on Kerberos trusts.

The trusts wil ltake care of the users on the fly.
Please get familiar with what we already did for AD trusts. It handles 
users without syncing them.
Similar will be done for other trusts.

>   Plus, putting the creation of IPA external users in the hands of an external service would seem to bind IPA and Ipsilon together when they don't need to be. If Ipsilon were a generic HTTP IdP<->Kerberos gateway, it would also work for AD, for vanilla Kerberos domains, and for KRB/LDAP domains. I'm not sure I would choose that unless there were no other options.

I think it will be pluggable to be able to create users in whatever 
identity store it is configured to create.

>
> However, "running code wins". Make me something that works and I don't need to look to closely at it. :)
>
>> Based on this discussion I suggest we open an RFE and plan for it when
>> we have:
>> 1) IPA <-> IPA trusts
>> 2) Ipsilon
>> implemented. Then we would be able to combine the two, add a call for
>> provisioning and finally help you solve the problem you are interested
>> in solving.
> I'm not sure I understand how #1 factors into this plan? Did I miss that bit?

This takes care of one of the types of the trusts you are worried about.


>
>> Are you interested in helping with moving 1) or 2) forward as a
>> prerequisite for the ultimate goal?
> Interest is rarely my problem; time is. :) Also, I need to wrap my head around things before coding. With regard to #1, I'm more or less itching to restructure trusts such that vanilla Kerberos is the general case,

Probably will be last in our list of Kerberos based trusts becuase I 
suspect that it would  be easier to move to IPA and then do the trusts.

>   and IPA->AD,

This is done. Please check it out.

> IPA->IPA,

Needs a lot of work. And this is where I suggest you can help.

> and IPA->KRB/LDAP are special cases where extra information may be available (email addy, gecos, sn, POSIX attrs etc.)

I think it is just easier to migrate to IPA and use IPA to IPA trusts. 
We already have use cases where extra data is needed from external sources.
There is a ticket in IPA trac. I just do not recall the number.

>
> For #2, I've been trying to find info on Ipsilon and failing. I have a vague notion that it's an HTTP gateway between web technologies and the Kerberos based IPA. Maybe I could interrogate someone and make a wiki page or three.

There is not much info about it. There is a site with code. It is a 
python based IdP focusing on making configuring SAML based SSO easy.
https://fedorahosted.org/ipsilon/

Simo, it might make sense to put some designs on the wiki for people to 
become familiar.

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

Bottom line. IPA <-> IPA is the next step.

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.