<html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <div class="moz-cite-prefix">On 04/19/2014 07:46 PM, Nordgren, Bryce L -FS wrote: </div> <blockquote cite="mid:82E7C9A01FD0764CACDD35D10F5DFB6E6B00D0@001FSN2MPN1-044.001f.mgd2.msft.net" type="cite"> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> <meta name="Generator" content="Microsoft Word 14 (filtered medium)"> <style></style> <div class="WordSection1"> I’ve run out of time for today, but the external collaboration pages are slowly evolving.<o:p></o:p> <o:p> </o:p> <o:p> </o:p> <a moz-do-not-send="true" href="http://www.freeipa.org/page/External_Users_in_IPA">http://www.freeipa.org/page/External_Users_in_IPA</a><o:p></o:p> <o:p> </o:p> 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.<o:p></o:p> <o:p> </o:p> <a moz-do-not-send="true" href="http://www.freeipa.org/page/Collaboration_with_Kerberos">http://www.freeipa.org/page/Collaboration_with_Kerberos</a><o:p></o:p> <o:p> </o:p> 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.)<o:p></o:p> <o:p> </o:p> Send comments to the list. I really appreciate Option A! Send more stuff I didn’t think of. </div> </blockquote> 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: <a class="moz-txt-link-freetext" href="https://fedorahosted.org/freeipa/ticket/3979">https://fedorahosted.org/freeipa/ticket/3979</a> 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. Bottom line: let us do practical steps in the right direction. The whole project seems to have too many weak points to try to solve it as a single use case. I would rather focus on building technologies that would gradually make life of collaboration domains easier and get there over time. Thanks Dmitri <blockquote cite="mid:82E7C9A01FD0764CACDD35D10F5DFB6E6B00D0@001FSN2MPN1-044.001f.mgd2.msft.net" type="cite"> <div class="WordSection1"> <o:p></o:p> <o:p> </o:p> Bryce<o:p></o:p> </div> 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. <fieldset class="mimeAttachmentHeader"></fieldset> <pre wrap="">_______________________________________________ Freeipa-users mailing list <a class="moz-txt-link-abbreviated" href="mailto:Freeipa-users@redhat.com">Freeipa-users@redhat.com</a> <a class="moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/freeipa-users">https://www.redhat.com/mailman/listinfo/freeipa-users</a></pre> </blockquote> <pre class="moz-signature" cols="72">-- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc.</pre> </body> </html>