[SSSD] could SSSD provide better integration with backends that PAM?

Jakub Hrozek jhrozek at redhat.com
Mon Feb 10 12:11:00 UTC 2014


On Mon, Feb 10, 2014 at 12:05:55PM +0100, Nikos Mavrogiannopoulos wrote:
> On Fri, 2014-02-07 at 11:11 +0100, Jakub Hrozek wrote:
> > On Fri, Feb 07, 2014 at 03:09:51AM -0500, Nikos Mavrogiannopoulos wrote:
> > > > On Thu, Feb 06, 2014 at 05:29:01PM +0100, Nikos Mavrogiannopoulos wrote:
> > > > > (The scenario that the vpn server would benefit, is the case where a
> > > > > user connects using TLS-client authentication, and the server -if it
> > > > > could obtain the client's public key from SSS- it would verify the
> > > > > client without any need for PKI).
> > > > Jakub is currently working on an interface to make extended user
> > > > information available via D-BUS. Assuming SSSD knows how to obtain the
> > > > clients public key would it help you if you can read it from D-BUS?
> > > 
> > > So I suppose you propose to perform PAM authentication, and after the user 
> > > is authenticated, to query sss over D-BUS with the username to get any additional
> > > information? That seems pretty ok with my use-case (though I'd prefer a C API).
> > > Is there any information on that interface currently?
> > 
> > Hi Nikos,
> > 
> > the current API design is here:
> > https://fedorahosted.org/sssd/wiki/DesignDocs/DBusResponder#TheDBusinterfacedesign
> > 
> > And here is how we propose to access additional attributes:
> > https://fedorahosted.org/sssd/wiki/DesignDocs/DBusResponder#Accesscontrol
> > Would something like this work for you?
> 
> Hello,
>  I see that the supported list of attributes isn't there. Is there going
> to be some standard list of attributes (and the attribute data formats)
> that will be available in multiple back-ends? Otherwise the caller
> should know about the backend and its names of the attributes, and that
> is only useful in an application that does targets a very specific
> system.
> 
> A small comment on the D-BUS API however, is that you replace the
> simple:
> sss_lookup_user_get_attr("santa", "telephoneNumber", &attr);
> 
> with
> org.freedesktop.sssd.infopipe.GetUserAttr(String username, Array of
> String attr_names) -> (Array of Dict { string, array } )
> 
> Why not provide a simple equivalent to sss_lookup_user_get_attr()? E.g.
> org.freedesktop.sssd.infopipe.GetUserAttrSingle(String username, String
> attr_name) -> (Array of Bytes)
> 
> regards,
> Nikos

Ah, sorry, I see the beginning of the page confused you. I left the
'legacy' API we used as a proof of concept in the design page to
maintain how we got to the current design, but since the legacy part was
confusing users, I simply removed.

I think the current API design, that starts in the section 'The DBus
interface design' contains a standard list of attributes and also
includes data types (since it's a DBus object, not just a dump from
LDAP).

Does this work better for you?



More information about the sssd-devel mailing list