Re: [Freeipa-users] External collaboration edits
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. #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.usmailto: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 required 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
Re: [Freeipa-users] External collaboration edits
On 06/07/2014 05:21 PM, 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. We start with AD views. When we get to IPA to IPA trusts we see how much of this applicable and or reusable. #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. You might be able to convince him to do SAML federation and stand up an IdP. This is why we are working on Ipsilon. #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 required 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. This is a standard problem of identity mapping. It is not solvable in general and has to be solved in the context of every namespace. In our case we use FQ names so we are pretty much guaranteed to have unique names. With Kerberos trusts one can just let external principal be and wonder around. If you do SAML you would have to create local principal and probably assign his external name that came from SAML as an alias. Kerberos supports aliases so it is the question of implementing it. I think we are going into the right direction with our efforts, it is just the question of time and demand. As time goes more and more interoperable solutions would be needed so the demand for identity collaboration will become more urgent. Right now we have many fishes to fry and cats to skin. Stay tuned. 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.
