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


Which in my case would be:


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:


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!

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 

Freeipa-users mailing list

Reply via email to