[Freeipa-users] External Collaboration Domains

[Nordgren, Bryce L -FS]

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

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

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

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

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

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.

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.

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.

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.

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.

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.

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.