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
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?
Senior Principal Software Engineer, Identity Management Engineering, Red Hat