[Freeipa-users] External Collaboration Domains

[Dmitri Pal]

On 04/11/2014 04:22 PM, Nordgren, Bryce L -FS wrote:
>> I guess we just do not see this scenario in practice yet.
> What I've found in the last decade is that scientists and CIO types cannot talk for lack of a common language. CIO types believe in closed systems over which they have complete control. Scientists are funded to work with others from other organizations. This is how they bring money into the organization, advance their careers, and perform the business of the agency. Talking exclusively with CIO types will actively prevent enterprise support of this collaboration domain notion from ever coming into practice. They will need ready to deploy tools in order to support this. Currently, standard practice is to kick us off the corporate network completely and hope we obey the tomes of security literature in our copious amounts of free time.
>
> We've been doing it forever. But it's been treated as exceptions to the rule by the CIO, instead of "this is how they operate all the time".  Hence, it's been at the small scale because it's been handled individually by members of every single project, few of whom have any patience for learning ldap or Kerberos.

We do not have much experience with setups and workflows as you 
describe. We are mostly serving the CIO's vision of "inside is my 
namespace".

OK so I think now I am ready to define a use case based on what you are 
describing.

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?

>> The users that come from an external realm would come via SAML or similar
>> and interact with a service provided by the local realm. In this case an
>> external user needs to be mapped to the role by the service.
> Here's where I don't think we're connecting. Services in the local realm include console logins via ssh, a stand alone processing box which the external user needs to tend, access to workgroup-scale HPC resources, or an sftp/nfs server.

I took a note of this when I wrote the use case above. Frankly this is 
the first time I hear about such case or more that IPA is relevant is 
such setups. May be it is finally grew to become relevant to reach new 
horizons.

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

>   We're always sharing code, setting up processing servers, setting up a shared data repository, etc. Web based services may play a big role, but it's never been the exclusive mechanism to my memory.

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.


>
>> Sorry I have a mindset that suggest that allowing external users to auto-
>> materialize in my internal enterprise domain servicing my infa is a bad idea.
>> May be it comes from the deep belief that the role of IdM is to only serve
>> local identities inside the local namespace and federate with other
>> namespaces using trusts or SAML and similar.
> I'm not sure we're disagreeing. However, unless you also believe that the role of the IdM is also to hobble the local realm such that it is only capable of supporting collaboration via web based services, something has to provide UID/SID/GID for external users. You cannot assume these are maintained elsewhere (i.e., if the user's home realm is SAML, OpenID, or vanilla Kerberos). Any synthesized UID/SID/GID parameters are contained within the local realm and do not apply in the realm of origin. The IdM is still serving the purpose you envision. It cannot authenticate these external users and does not manage their passwords. It just makes sure that the necessary attributes are present within the local realm, and that the set of necessary attributes is self consistent.
>
> These suggestions are for an explicitly created collaboration realm which has a one-way trust from the host organization's internal infra to the collaboration domain. Nothing will "auto-materialize" on the internal corporate network. None of these services are offered on the internal corporate network.

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?

I am not sure I understand the authentication workflow in this case but 
may be it is listed below...




>
>> Can you give me an example of a real world scenario when a local domain
>> would welcome user accounts to be synthesized out of the thin air?
> A] It's not out of thin air. Proof of identity must be established via Kerberos trust, PKINIT or authentication against an external identity provider (SAML/OpenID). I'd want control over whether the realm is setup with a whitelist or a blacklist of IdPs, and what's on that list.

This is where I have a bit of a problem because we have a protocol mixture.
I can understand if an external user access a web application (lab 
control like OpenStack or something like) to launch a VM or a job. In 
this case he can be authenticated against external trusted IdP via SAML 
or such but then his POSIX attributes are not needed.

If this user then tries to SSH into the system there are three options:
a) Use user name and password - but this means that user needs to have 
an account in the hosting domain this he is effectively just added to 
the hosting domain as a full account
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.
c) SSH keys or Certs - they need to at least be uploaded and trusted by 
the hosting realm but they can be managed by hosting realm too and given 
to the user.

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.



>
> B (background)] My organization operates an Enterprise AD as well as two SAML identity sources. Getting someone in AD involves paperwork, a 4-6 month delay, and background checks, conferring on them full privileges to the enterprise network. In addition, AD is completely inaccessible to the cooperator unless we buy them a corporate imaged machine and require that they VPN in to the corporate network to get credentials for the public-facing collaboration realm. The SAML IdPs are segregated by the degree of assurance of the user's identity (level 1 is basically self registration with an email account; level 2 is you show up at a USDA service center with your driver's license, and you might also have to have a sponsor). Neither SAML credential permits access to the enterprise network. Our SAML IdPs are public-facing. So right off the bat, even if we're not part of a SAML federation, it's better to get cooperators SAML identities than AD identities because its more appropriate to the level of access they need and the means of access they possess...so long as they can ssh in, share files, and participate in groups.

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.

> C] If I am trying to ssh into one of our collaboration resources when I'm visiting a collaborator, I'm forced to use my SAML credentials because I can't reach AD. Because we will not be synchronizing all users against our SAML IdPs, my SAML account must be autocreated.

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.
If we admin that we can't make a leap of faith then we get to the scenario:

a) Once has to register external users and give them local passwords.
b) These accounts can be linked to the external IdPs so that if the user 
comes from the external source using SAML then he is trusted and mapped 
to his local account.

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

Here is how it might work:

User from a remote domain hits a service in the hosting domain for the 
first time.
Service redirects to Ipsilon IdP for assertion.
Ipsilon redirects back to Org IdP to provide assertion or authenticate 
using OpenID (or like)
The dome domain presents a proof of the authentication.
Ipsilon sees that this is a trusted users and does a lookup in the home 
domain.
The user is not found.
Ipsilon creates user and save the mapping of this user to the external 
identity source in additional attributes.
It then issues an internal SAML assertion for the newly created identity 
and redirects user to the application.
Application checks that it is an assertion from Ipsilon and lets user in.

If user then tries to SSH he is asked to change and set his password and 
no he is a full user that can access the hosting domain (it might be 
collaboration domain as you call it) both ways.

The next time user uses the service there will be the same workflow but 
the entry will be found and thus the assertion will be issued right away.

I think it makes sense.
It is just a bit down the road for Ipsilon. We have not been drilling 
down in this direction but IMO it is possible.
I would like to hear Simo's opinion on this matter.




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

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

>
> F] Users from SAML/OpenID based sources also need to participate in groups, for this they need a DN and therefore must be autocreated.

:-) ^

>
> G] Users holding valid grid computing credentials (also kx509 certificates) should be autocreated. (again, admin control over whitelist or blacklist of IdPs would be desirable.) Again, they need to be able to participate in groups, requiring a DN, requiring autocreation.

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.


>
> Note that all the above represents authentication. Individual machines and services will be configured by the system owners for authorization. (e.g., before sshing from a collaborator's facility, I'd have to set my machine up to authorize my SAML credentials.) Also note that nearly everyone is an external user to this collaboration domain, even the users managed by the host organization.
>
> Yes, we do have a collaboration domain in real life (limited to me, our research group and about 100 explicitly managed external users). Yes our CIO is evaluating how to support such an activity at scale. No, the solution I describe here is not implemented. This is my wish list after doing this for a decade and creating accounts on individual machines.
OK this all makes sense.
The only difference in the views is that IMO this auto creation is not a 
function of IPA's KDC but rather of the external IdP like Ipsilon that 
has the while list and black list and for the identities coming from 
white list sources it can optionaly issue user add command.

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.

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.

Are you interested in helping with moving 1) or 2) forward as a 
prerequisite for the ultimate goal?

Thanks
Dmitri


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


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.