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

Dmitri Pal dpal at redhat.com
Mon Feb 10 19:22:21 UTC 2014


On 02/10/2014 08:27 AM, Jakub Hrozek wrote:
> On Mon, Feb 10, 2014 at 01:59:48PM +0100, Nikos Mavrogiannopoulos wrote:
>> On Mon, 2014-02-10 at 13:11 +0100, Jakub Hrozek wrote:
>>
>>>> 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.
>>> 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 that the comment still applies. The attribute that I am
>> interested at (user's public key) is -according to my understanding- on
>> the extraAttributes, and the only text available is:
>> property Dictionary extraAttributes
>>      Extra attributes as configured by the SSSD. The key is the attribute
>> name, value is array of strings that contains the values.
>>
>> So I'd still be interested whether the extra attributes will contain
>> some consistent set of attributes across different SSSD installations,
>> or they would be system-specific.
> The extra attributes are defined in sssd.conf, which is per-client, so
> the set would only be consistent if the sssd.conf is consistent across
> client installations. In your case you'd have to add something like:
>   [ifp]
>   user_attributes = +sshPublicKey
>
> We simply can't expose all the attributes on the bus, you don't want to
> expose the cachedPassword for example.
Nikos?

How else can you do it?
We see it this way: your LDAP has some attribute that you want to expose 
so you tell SSSDs in your deployment to fetch it and expose it. What is 
wrong with this approach?

> _______________________________________________
> sssd-devel mailing list
> sssd-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/






More information about the sssd-devel mailing list