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

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 
trusts, including:
* 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
> autocreated.
> 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 
> 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.

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

Reply via email to