On 04/10/2014 05:40 PM, Nordgren, Bryce L -FS wrote:
Close. The problem is to expose kerberized services in the local realm to
users holding foreign credentials, supporting SSO wherever possible. This
includes file sharing via NFS, kerberized web apps, ssh logins, and anything
else the local realm has to offer. SSSD can handle ssh logins (if one considers
it "handled" to transmit the password over the wire and abandon SSO), but
cannot handle the former two.
This is already handled with the trusts feature with AD. It is handled by SSO
and using Kerberos ticket renegotiation between two domains.
The similar approach would work for IPA to IPA and IPA to Kerberos. In the
IPA to IPA case we will have authorization data in the ticket that would help
with this.
I am sorry I fail to see a driver and use case here. But may be I am missing
something obvious.
Trusts are only feasible between tightly coordinated realms and with the
involvement of admins. The use case is a collaboration realm, where users (not
admins) drive the connections between realms. This precipitates everything in
the proposal. If the user is coming from an AD realm, there may not be a trust,
and it may be inappropriate to have an admin form one if there are only three
or four users binding the two realms together. The AD realm may be behind the
institutional firewall and the KDC inaccessible, making PKINIT a good choice.
Perhaps kx509 certificates are not available from the home realm, making OpenID
or SAML a good choice.
A theme in your previous message was that some use case is already covered
because the admin can explicitly take some action to handle it, and each
instance (each new trust) needs to be individually created and then managed.
The point of this RFE is that the admin can set up a realm which responds to
how users travel from realm to realm, offering both flexibility for the manner
in which users authenticate and consistency for the services offered by the
realm.
It's a different mindset that makes the use case invisible. :)
I guess we just do not see this scenario in practice yet.
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.
Such user does not need to have a special user account, principal,
UID/GID as he is not going to access the vanilla services and
infrastructure on the low level. He is sort of guest, a tenant, and will
be handle by a provided service rather than infra. The service can cache
the user information for future but not more than that.
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.
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?
Thanks
Dmitri
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.
--
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
