> -----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. This may > be something which deserves an honorable mention on the RFE page as it > impacts the assumptions coders can make. > > I wonder if you mean that the reference in the user views may not always be > single valued ? Potentially. I'm unfamiliar with the implementation details, so let me start talking "end user visible" features. I want one user profile for me in the domain. All domain clients recognize this profile. I want my username to be short and sweet. I want to have the option of authenticating using a variety of methods (Kerberos, saml, openid connect), but I do not want these to be completely separate accounts. I want to connect my authentication sources to my profile so that it doesn't matter where I log in from/how I log in. Again, long story short, don't worry about the details of how these various authentication sources are bridged into Kerberos. Assume they are (or will be). The view should be thought of as a domain-wide user profile which is attachable (under user control) to multiple authentication principals. > Thank you very much for your input. I plan to update the design page during > the next days. I hope you don't mind if I add your suggestions in a 'Next > step/Future Enhancements' section because I would prefer to get the AD > use case implemented and included in the IPA and SSSD trees first. I think overwriting the username and other machine specific attributes has to go in at first, even with just AD. Not doing that assumes you're either dealing with a single foreign AD domain, or foreign AD domains which are somehow coordinated to eliminate username/uid collisions. Certain names may be more problematic than others. Jsmith may be more likely to collide than bnordgren, for instance. And large directories have a greater potential for collision than small ones. Everything else can definitely be a future thing. Thanks for your work! 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
