On Tue, Jun 30, 2015 at 02:00:16PM +0200, Jakub Hrozek wrote:
On Tue, Jun 30, 2015 at 01:47:01PM +0200, Jan Pazdziora wrote:
My only concern is that the domain name as returned by sssd is lowercase which does not really match the realm as seen by say mod_auth_kerb or mod_auth_gssapi. But I guess uppercasing the string is up to consumer of that value.
That really depends on what the expectation is and what is the use-case.
The expectation is for the user to be able to authenticate either via Kerberos or via PAM (with optional subsequent access check) a have the user identifier (the long one) uniquely identify the user record from application's point of view. So ideally it needs to be the same string.
Currently the code seems to return the name of the sssd domain section the user authenticated with. That is more or less just a label and can be really anything.
On the other hand, that's the part after the '@' character which allows the clients to ask sssd daemon questions (via PAM, via D-Bus) and know that they uniquely (from the SSSD point of view) address that single user record they want. And I assume SSSD uses it internally as well for namespacing purposes. So the admin is not expected to change that section every hour, it's supposed to be reasonably stable.
If for the applications realm is also useful, then a) the app can query the sssd dbus interface for the matching realm for the domain b) we can also return the realm, although the expectations should be set right in documentation that not all domain types have the realm info (LDAP domain for example)
So how about the reverse mapping? Going from realm to SSSD domain / section? Currently for example in mod_authnz_pam we consider them interchangeable -- we just take the principal name (either fully qualified or not) and pass it to pam_sss.so via pam_acct_mgmt to evaluate the access check. Should we get the SSSD domain / section value for that?