On 04/11/2014 08:47 PM, Nordgren, Bryce L -FS wrote:
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?
Probably not. But this is not significant for the design.
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. :)
We will see when we get there. I am all for it but I see much easier
ways of the federation via other means in shorter time.
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.
You can get the ticket on the server but you can't deliver it to the
client side.
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.
There is no way to deliver TGT to the client. Also there is no TGT on
the server. TGT can be acquired only using the real credential by
principal in the initial auth. But this means that principal has a local
credential (password, cert, token...). But this means it is not an
external account any more.
Full stop. Sorry.
GSSAPI/OpenID->GSSAPI acceptor->TGT->Service TKT->SSH. Like normal. or
Does not work. Not possible. You can't get TGT using any kind of service
ticket.
GSSAPI/SAML->GSSAPI acceptor->TGT->Service TKT->SSH. Like normal.
See above. This is the flaw in the whole idea.
As I said there are two problems:
a) You can't get TGT using a service ticket
b) If you got a ticker on the server side there is no way to deliver
this ticket out of band not over kerberos protocol and stick it into the
client.
Knowing Kerberos community for 6 years I would say the chances for this
to change are close to 0. I am not sure wheather it is even a good idea
to change it. Also the change would require a change to all the browsers
and this is a showstopper in itself.
I think it would be easier to create an SSH client plugin that uses
existing protocols and flows but it is again a huge task in itself.
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. :)
There is no way to send the ticket back to the client. gateway itself
would not have access to that ticket too. It can act on behalf of the
user but not send tickets around.
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?
Kerberizing something is very hard. We have been doing it for many years
and the pace is really slow.
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. :)
The AD accounts are already taken care of but the AD trust feature,
please setup a trust and see for yourself.
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. :)
You are assuming what Kerberos can and can't do thus you have design
that has some fundamental flaws.
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.
The trusts wil ltake care of the users on the fly.
Please get familiar with what we already did for AD trusts. It handles
users without syncing them.
Similar will be done for other 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.
I think it will be pluggable to be able to create users in whatever
identity store it is configured to create.
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?
This takes care of one of the types of the trusts you are worried about.
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,
Probably will be last in our list of Kerberos based trusts becuase I
suspect that it would be easier to move to IPA and then do the trusts.
and IPA->AD,
This is done. Please check it out.
IPA->IPA,
Needs a lot of work. And this is where I suggest you can help.
and IPA->KRB/LDAP are special cases where extra information may be available
(email addy, gecos, sn, POSIX attrs etc.)
I think it is just easier to migrate to IPA and use IPA to IPA trusts.
We already have use cases where extra data is needed from external sources.
There is a ticket in IPA trac. I just do not recall the number.
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.
There is not much info about it. There is a site with code. It is a
python based IdP focusing on making configuring SAML based SSO easy.
https://fedorahosted.org/ipsilon/
Simo, it might make sense to put some designs on the wiki for people to
become familiar.
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.
Bottom line. IPA <-> IPA is the next step.
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IdM portfolio
Red Hat, Inc.
_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
