> 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 

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 

> 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 t!
 o 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 

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 

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 

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.


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