> 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
> 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?
> 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. :)
> 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.
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.
GSSAPI/OpenID->GSSAPI acceptor->TGT->Service TKT->SSH. Like normal. or
GSSAPI/SAML->GSSAPI acceptor->TGT->Service TKT->SSH. Like normal.
> 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. :)
> 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
* 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@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?
> > 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
> 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. :)
> > 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
> 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. :)
> 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. 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.
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?
> 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, and IPA->AD,
IPA->IPA, and IPA->KRB/LDAP are special cases where extra information may be
available (email addy, gecos, sn, POSIX attrs etc.)
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.
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