On Fri, 2014-04-11 at 17:58 -0400, Dmitri Pal wrote: > > 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. > > 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. > If we admin that we can't make a leap of faith then we get to the > scenario: > > a) Once has to register external users and give them local passwords. > b) These accounts can be linked to the external IdPs so that if the > user > comes from the external source using SAML then he is trusted and > mapped > to his local account. > > 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. > 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. > > Here is how it might work: > > User from a remote domain hits a service in the hosting domain for > the > first time. > Service redirects to Ipsilon IdP for assertion. > Ipsilon redirects back to Org IdP to provide assertion or > authenticate > using OpenID (or like) > The dome domain presents a proof of the authentication. > Ipsilon sees that this is a trusted users and does a lookup in the > home > domain. > The user is not found. > Ipsilon creates user and save the mapping of this user to the > external > identity source in additional attributes. > It then issues an internal SAML assertion for the newly created > identity > and redirects user to the application. > Application checks that it is an assertion from Ipsilon and lets user > in. > > If user then tries to SSH he is asked to change and set his password > and > no he is a full user that can access the hosting domain (it might be > collaboration domain as you call it) both ways. > > The next time user uses the service there will be the same workflow > but > the entry will be found and thus the assertion will be issued right > away. > > I think it makes sense. > It is just a bit down the road for Ipsilon. We have not been drilling > down in this direction but IMO it is possible. > I would like to hear Simo's opinion on this matter.
I assume this could be done, to some degree. With SAML you wouldn't be able to check anything in the user's own SAML IdP unless the 2 organizations Idp's have been previously linked. With OpenID connect it may be possible to pull information if the other organization system allows their users to trust arbitrary applications, but it may not be always allowed. The main issue I see is that this would only allow to create a user, but it is unclear to me how this would allow SSO, we could store a cookie with the user's name from the Idp, so that if the user uses always the same browser it may be automatically chained to its Idp of origin, otherwise at least a username or password will have to be provided by the user. > It is indeed a bit down the road, but we can start thinking about these scenarios now ... from the POV of Ipsilon this chaining and cookie and all would basically just be a login plugin, shouldn't require any additional code in the core. Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
