Re: [Freeipa-users] External collaboration edits
-Original Message- From: Sumit Bose [mailto:sb...@redhat.com] Sent: Tuesday, June 17, 2014 3:27 AM Case one would represent vanilla Kerberos trusts, or the quite likely scenario where an external collaboration domain is separated from corporate AD by a firewall. (e.g., institutional AD can provide authentication via trust for users on the corporate network, but not attributes). I think this can be done. It is about how the reference key is evaluated. E.g. if the key is ':KRB5:u...@example.com' in the default view SSSD can create a user object in its cache with the data given in the view and where the user name is equal to the Kerberos principal name (so far we said that we do not want to allow to overwrite the user name in views to avoid confusion). Since the object is now in the SSSD cache it is available in the IPA server, on IPA clients with SSSD via extdom plugin and to legacy clients via the compat tree. I hate to appear too stupid, but google isn't getting me where I need to be fast enough. What's the extdom plugin? Also I think I'm losing track of the flow. Is the above talking about SSSD on one of the domain clients, or on the FreeIPA server? I'm not sure I understand how an object in the (client's?) SSSD cache becomes available to FreeIPA, and hence to all domain clients... I think you may have to allow overwriting the username in views, unless there is some other mechanism to allow the domain admin to resolve username collisions. I don't think views should ever touch the user's real name fields, or email, or things which actually apply to the human behind the identity. However, I'm thinking of views as the means by which an externally defined identity is adapted to the local computational environment. Overriding username, uidNumber, group membership, and other stuff relevant to using the remote identity in the local context is all fair game. Individual cross-realm principals may be the norm for onsey-twosy logins from foreign domains where its impractical to establish trusts. These will have the form: USER/external@example.com Which in my case would be: bnordgren/ds.fs.fed...@firelab.org That's awful long, and the slash in the middle means that the home directory can't just be the username. Principals from foreign technologies may be longer, and also full of stuff that can't be in a directory name. We don't know what those will look like yet, but the username may have three components and contain a URL. Say this is the Kerberos version of my SAML principal: bnordgren@fs/SAMLv2.0/https://www.eauth.usda.gov/Login/login.a...@firelab.org Long story short, don't worry about how the nasty principals get generated, but do assume that they are too ugly for words. Please please please overwrite my username. :) Case two would represent authentication sources such as SAML. Views would need to be the mechanism by which the gateway caches attributes in FreeIPA (after inspecting SAML assertions). I think we are already doing similar things with the MS-PAC. If configured SSSD will intercept the PAC, decode it and store data from the PAC in the cache. This currently happens during authentication on the client hence this data is directly available on the IPA client and is not distributed by the IPA server. Would this work for you use case or do you need the data on IPA clients where the user never authenticated as well? I think that if FreeIPA intends to provide infrastructure which offers clients the option setting up file sharing via nfsv3 or v4 using host-based auth, the uidNumbers all have to be the same for all domain clients. I'd vote for supporting filesharing. NFSv4 with Kerberos auth may tolerate the uidNumbers being different, at the cost of making sssd manage the idmapper. If there's no file sharing (users log into isolated workstations and touch only local files or scp/sftp/sshfs files back and forth), then each machine needs to allocate a persistent identifier which lasts from session to session. Is the SSSD cache persistent between logins? However, this won't recognize that me logging in via Kerberos is the same as me logging in via SAML. (see below) So I guess this is a very longwinded no, it won't work for me. Sorry. :) Needs to be consistent in the domain. Finally, one functional requirement for views may be that the view needs to support a many-to-one authentication method to identity attributes mapping. For instance, an employee sitting at their desk may log into their server in the collaboration network via SSO (hence, their AD account). Soon this same user may also walk over to the console on the collaboration network and need to use some other Ipsilon-gateway-enabled credentials. These two credentials may need to be mapped to a single user identity. This may not be functionality which needs to be implemented first, but it does perhaps suggest that krbPrincipal may not always be single valued.
Re: [Freeipa-users] External collaboration edits
[...talking about views...] 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. Can views handle the case when there is no upstream object? Or when the upstream attribute store is not published as a searchable database (which is almost no upstream object)? I'd very much like to see these as explicit use cases for views. Case one would represent vanilla Kerberos trusts, or the quite likely scenario where an external collaboration domain is separated from corporate AD by a firewall. (e.g., institutional AD can provide authentication via trust for users on the corporate network, but not attributes). Case two would represent authentication sources such as SAML. Views would need to be the mechanism by which the gateway caches attributes in FreeIPA (after inspecting SAML assertions). Finally, one functional requirement for views may be that the view needs to support a many-to-one authentication method to identity attributes mapping. For instance, an employee sitting at their desk may log into their server in the collaboration network via SSO (hence, their AD account). Soon this same user may also walk over to the console on the collaboration network and need to use some other Ipsilon-gateway-enabled credentials. These two credentials may need to be mapped to a single user identity. This may not be functionality which needs to be implemented first, but it does perhaps suggest that krbPrincipal may not always be single valued. This may be something which deserves an honorable mention on the RFE page as it impacts the assumptions coders can make. Thanks, 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 https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] External collaboration edits
On Sat, Jun 07, 2014 at 09:21:29PM +, 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.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 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
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. http
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. 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 Bryce This electronic message
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. Last week was Red Hat summit. Things piled up. I will try to get to these pages by the end of the week. 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 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] External collaboration edits
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. 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 https://www.redhat.com/mailman/listinfo/freeipa-users
