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