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.


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

Reply via email to