On Sat, Jun 07, 2014 at 09:21:29PM +0000, Nordgren, Bryce L -FS wrote: > Dimitri, thanks for the reply! Pls forgive my lateness. > > I fear I am not currently up to fighting with MS Outlook to convince it to > let me respond inline. It wants to block quote your entire message and if I > type in the middle it keeps the "quoted" style. > > In any case: > > #1] Making small things work first and accumulating functionality is > definitely the way to go. If it were simple and straightforward, everyone > would be doing it already. > > #2] I looked at "views" (Ticket 3979 as well as > http://www.freeipa.org/page/V4/Migrating_existing_environments_to_Trust). I > think I follow most of it (a default view which applies to the whole domain, > custom views which may be applied to particular targets). +1 +1 +1. One > concern I have is that the design page seems to be written around a single > upstream source (trust with AD). What happens if there are many "upstreams"? > All in all, though, it sounds like my current RFE is a duplicate of views. If > we could add in my use case to the Views ticket/design, we can close mine out.
It's not only about AD, but use-case and examples in the design page currently all refer to AD. The key is to find a unique reference to the upstream object which in the AD case is obviously the SID. In a previous version of the page there were a bit more details who the original/upstream objects can be referenced, e.g. it can a fully qualified name or Kerberos principal. bye, Sumit > > #3] Kerberos based auto provisioning will fall apart if the authentication > path cannot be walked by the client (not the FreeIPA server). When I'm > sitting in my office, I can see my KDC as well as the collaboration > environment, and I can walk the path. However, if I cannot convince my CIO to > poke a hole in the firewall so that FreeIPA in the collaboration domain can > get to the internal AD (to query attributes, etc), then an AD trust is not > possible and a vanilla Kerberos trust is all that is available. > Kerberos-trust based auto-provisioning may be able to handle situations that > AD trusts can't. By and large, I need my boxes to know my username, and could > care less if they know my givenName, sn, mail, telephoneNumber, etc. As long > as FreeIPA can synthesize a uidNumber for me in the absence of an SID, the > rest is gravy. > > #4] One user/Many Accounts. This is an unavoidable reality. Also, there's a > namespace collision issue here. My Kerberos cname@crealm is > bnordg...@ds.fs.fed.us<mailto:bnordg...@ds.fs.fed.us> as issued from my AD. > My SAML uid is "bnordgren@fs" from > https://www.eauth.usda.gov/Login/login.aspx. My Google OpenID is bnordgren > from "wherever". There is also a "bnordgren" from a university out of SLC, > Utah. I occasionally get mis-addressed email for him. Typically spam, but > once from his mom. Fundamentally, whenever multiple domains are consolidated > into a single namespace (as is already a use case for views), one typically > tries to avoid username collisions just as vigilantly as they try to avoid > uidNumber collisions. What is needed here is a method for the users to > override the default collision avoidance such that they allow all of their > accounts to be mapped onto their One True Username for the domain. In the > spirit of point #1, implementing collision avoidance will be require! d for views, so it needs to happen now even without external collaboration. Figuring out how to let users override it can happen in the future. > > > Bryce > > > From: freeipa-users-boun...@redhat.com > [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Dmitri Pal > Sent: Wednesday, May 14, 2014 4:13 PM > To: freeipa-users@redhat.com > Subject: Re: [Freeipa-users] External collaboration edits > > On 04/19/2014 07:46 PM, Nordgren, Bryce L -FS wrote: > I've run out of time for today, but the external collaboration pages are > slowly evolving. > > > http://www.freeipa.org/page/External_Users_in_IPA > > Dimitri observed that my RFE page was too long. I observe it also has too > much stuff unrelated to the actual meat of the RFE. So I factored out most of > the Kerberos stuff into a different page. I also tried to focus the RFE to > just creating entries in LDAP for external users so they can: a] participate > in POSIX groups; and b] have locally-defined POSIX attributes. > > http://www.freeipa.org/page/Collaboration_with_Kerberos > > This is where all the Kerberos stuff went. I also added in "Option A" from > Petr's email. Option B will come along later, when I pick this up again. > Mechanism three has more to do with Ipsilon than IPA, and basic functions > required of the Ipsilon gateway server are articulated there (regardless of > the particular authentication method.) > > Send comments to the list. I really appreciate Option A! Send more stuff I > didn't think of. > > Hello, > > > I finally read the pages, sorry for the delay. great writeup! > > Here are some comments. > > 1) You are right that we need to have a record in IPA to be able to have a DN > and take over some of the posix attributes. We already have this use case and > this is a high priority. We call it views: > https://fedorahosted.org/freeipa/ticket/3979 > Once this is implemented we will have mechanism to have a local entry without > credential for the external user. > 2) The second issue is provisioning as automatic as possible. And this is > where there will be some issues. > If we want to leverage Kerberos trusts then two things should happen: > a) the trust should first be established > b) the home realm should be accessible for the KDC in the collaboration > domain. > This rises practical operational questions about what is the home domain. If > the home domain is another collaboration domain then user is natively have > been created in that domain and has his credential in that domain. Hm but > that violates the idea that the collaboration domains have external > "auto-provisioned users". If the home domain is the internal domain than most > likely the cross forest trust can't be established because admin of the > internal domain would not want to expose his domain to somebody's external > domain on the internet. > So IMO the kerberos based auto-provisioning falls apart. > > However if we use a gateway that would allow a person to self register and > use technologies similar to OpenID then we would be able to create his own > account. The gateway would check that the user is from some trusted source > that is configured for that domain. We would have to figure that part out. > But IMO this component is external to IPA. It is a similar gateway to > Ipsilon. I suspect that as we move forward Ipsilon will transform from an IdP > server to being a collection of "gateway services". One would be able to > deploy IdP instances, Kerberos -> cert service, account registration service > etc. > > This would rely on some of the functionality in IPA but can evolve > independently. > IMO if we go this path and you are interested in contributing to this effort > we can start prototyping such service. > We can start simple: create a service that allows one to authenticate using > google or facebook and once user authenticated agains one of them call an ipa > user-add against IPA. > That would be a good first step towards what you want to accomplish. > Then it can be enhanced to redirect to an external IdP (Ipsilon). Then the > setup will be: > > * User connects to the self registration portal. > * Portal reditrects him to the IdP that is configured for the portal > * IdP performas an authentication against user home domain and creates > assertion > * Assertion is presented to the registration portal > * The portal gets user infor from the assertion and adds a user > > It also seems that OpenID connect might be quite relevant here. > So exploring how it can be used in in conjunction with registration portal > would be another path. > > 3) The problem of the credential yet stays open. If the user can be created > in different ways it might not be quite easy for the user to know or remember > that he must use his kerberos/Google/facebook or other credential wit ha > specific domain. May be we should consider creating a full user also with a > password or OTP token to access the collaboration domain. Then user would > always know that he needs to use his token. I wonder if actually just OTP > would be a good option in this case. It can be provisioned to the freeOTP app > at the moment of the user registration. > > > > 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. > > > > _______________________________________________ > > Freeipa-users mailing list > > Freeipa-users@redhat.com<mailto:Freeipa-users@redhat.com> > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > -- > > 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 _______________________________________________ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
