SSSD: More than an LDAP client

OpenSUSE Conference 2016

Jakub Hrozek

About me and the talk

Red Hat developer, working on SSSD full time

Also working on cwrap, cmocka, FreeIPA and other stuff

This talk is mostly about SSSD

What exactly is this talk about?

A bit different than the talk description

Hopefully more useful!

More developer-centric

Not only about SSSD, but also the ecosystem around it

Demos!

My goal

Show you how to make your life easier with SSSD

Get more users

Get more contributors

Get more bug reports :-)

Make better software for everyone

My goal of travelling here and giving this talk is to improve SSSD, because it's a project that is dear to me and I think it has some very nice features not many people know about. Especially lately, we are adding features that make it possible to use SSSD's powers in applications through API and can make your life easier. Of course, I hope to get more users, ideally more contributors, because historically, most of the contributions we have are from red hat developers. And even bug reports count as contributors, if you end up trying something out after this talk and it doesn't work, please don't hesitate to tell us. Contacts will follow after the talk.

SSSD 101

SSSD is a system daemon

Allows access to remote resources that provider identity, authentication and policy data

Fetching data like usernames, user ID from a server, authenticating against the server

Mostly LDAP, Kerberos, Active Directory, FreeIPA

The "traditional" interfaces SSSD provides are NSS and PAM

Caching of identity data and passwords

Resiliency and performance

SSSD uses an on-disk cache

The cache stores identity data, optionally password hashes

Very fast in-memory-cache

Cleartext passwords can be stored in the kernel keyring

Demo - Jakub's laptop

Look ma, no user in /etc/passwd

Supported back ends

LDAP

Kerberos

Active Directory

FreeIPA

Not just passwords

One-time-passwords

Smart Cards

Demo - OTP login support

IPA + FreeOTP

Policy access and evaluation

sudo

GPO (only..so far) for access control

SSH keys for users (generic LDAP) and hosts (IPA only)

Demo - Centralized sudo policies

Uses IPA, but works with LDAP or AD as well

SSSD doing the hard work of talking to the server

Would be nice to support AD GPOs..

Service discovery and failover

Service discovery centralizes config

Failover suppresses single point of failure

Enterprises need to set server affinity centrally

SSSD for apps

There is a lot of functionality in SSSD

..traditionally only available on the OS level

Applications solve the same problems

The whole reason I showed you all the functionality in SSSD in the first part of the talk was to get you exicted about SSSD. As I shown in the first part of the talk, SSSD offers a lot of functionality. This functionality solves real world problems like reading data about users from a corporate server. These are problems many applications have to solve, because those applications have to integrate with the same environment SSSD integrates with. Wouldn't it be nice if this functionality was available to any application? Of course we think it would and we implemented an interface in SSSD to allow anyone to access SSSD's functionality

Integration user stories

A desktop application needs to display a phone entry of a user who logs in from Active Directory

A web application needs to display groups an LDAP user is a member of and manage access based on the group membership

Administrator wants to centrally manage access to applications in the corporate AD servre

...many more

ldapsearch is not the best idea

You shouldn't just implement the functionality

What about authentication?

What about caching?

What about fail over?

What about all the different way of retrieving the groups of a user?

What about resource consumption in containerized environments?

Meet the InfoPipe

SSSD implements a D-Bus interface

Lets you access the data SSSD knows about

Users, groups, domains and their status

Lookups by name, ID, certificate, ...

A detour: Why D-Bus?

The Linux IPC

Rolling out your own IPC is a bad idea

Bindings for all major languages

Access control

Discoverable, introspectable

Data types, type safety

Notification with signals

We chose to implement the SSSD API with the help of D-Bus. It might seem counter-intuitive at first, because D-Bus is often thought about as 'the desktop component', but really, there's so many advantages to D-Bus that it's very hard to beat. The most obvious idea is that we're in the business of implementing a service that deals with accessing remote resources, not in the business of implementing an IPC. D-Bus provides us with interface that all major programming languages support, whether it's C for your low-level system service or Ruby for a web application. This is a win-win, because we don't have to spend time writing bindings and you don't have to spend time writing language bindings for our home-grown API. D-Bus also provides fine-grained access control, down to per-interface or per-method or integrating with PolicyKit. D-Bus allows your interfaces to be introspected by admins or programmes so that they can see during runtime what's available. D-Bus also has support for data types, so if your interface specifies that it accepts a string, on the side of the app and also your deamon, you don't have to care about boundary checks, you just read strings from the API. There are also rich types, like structs or dicts.

Demo - Accessing user data with InfoPipe

Let's find out admin's phone number

From shell and from Python

Demo notes

The service is called ifp in sssd.conf

By default, only root can talk to it

Other users can be added with the allowed_uids option in the [ifp] section

polkit integration scheduled for the next release

Demo notes

By default, only the standard POSIX set of attributes can be retrieved

Additional attributes can be configured in sssd.conf

Two places to edit in sssd.conf

tell SSSD what extra attributes to fetch from server
ldap_extra_user_attributes = telephoneNumber
allow these attributes to be served via the D-Bus interface
user_attributes = +telephoneNumber

Authentication for apps

So far only PAM

Too tied to the OS-level

Do we want to be in the business of building an auth API?

Links

Documentation is not our strongest side..

We have generic docs about the D-Bus responder

And about the user and group objects

Demo - SSSD status APIs

SSSD also publishes info about itself on the bus

Great for writing status utilities

Discoveratble, let's see with d-feet

The SSSD ecosystem

realmd lets you configure SSSD

mod_lookup_identity is a real world user of the D-Bus interface

realmd - the realm discovery service

https://freedesktop.org/software/realmd/

D-Bus service, not a deamon

Configures authentication and domain membership

Demo - discovering and joining domains with realm

realm discover

realm join

Implemented by calling D-Bus API of realmd

Integration point for Yast?

Apache module mod_lookup_identity

https://www.adelton.com/apache/mod_lookup_identity/

Real life SSSD D-Bus client

Attributes and group membership for an authenticated user (REMOTE_USER)

To be consumed by Web application

Apache module mod_lookup_identity

LookupUserAttr mail REMOTE_USER_MAIL

Application then retrieves the REMOTE_USER_MAIL variable

Supports lookups by certificate as well

We're not done yet

SSSD is still under heavy development

Come and join us!

All your users are belong to us

SSSD traditionally manages remote users

Wouldn't it be nice to manage also local users?

Linux has no interface to manage them yet..

Most tools are limited to the POSIX set of data

Herding secrets with Custodia

Custodia

a server that allows to store secrets centrally and access them over a network

useful for bootstrapping cloud environments

no passwords in VM images anymore

REST API

https://github.com/latchset/custodia/wiki/architecture

Herding secrets with SSSD

Secrets need to be accesible at the system level, too

SSSD exposes the Custodia REST API over a UNIX pipe

Per-application namespace, think [secrets/system/httpd]

Access control with SO_PEERCRED and SELinux

Local storage in SSSD cache or routing to remote Custodia instance

Work in progress so far, no demo, sorry

Suse demo

Howard shows how sssd works in suse

youtube video

SSSD: More than an LDAP client

OpenSUSE Conference 2016

About me and the talk

What exactly is this talk about?

My goal

SSSD 101

Caching of identity data and passwords

Demo - Jakub's laptop

Supported back ends

Not just passwords

Demo - OTP login support

Policy access and evaluation

Demo - Centralized sudo policies

Service discovery and failover

SSSD for apps

Integration user stories

ldapsearch is not the best idea

Meet the InfoPipe

A detour: Why D-Bus?

Demo - Accessing user data with InfoPipe

Demo notes

Demo notes

Authentication for apps

Links

Demo - SSSD status APIs

The SSSD ecosystem

realmd - the realm discovery service

Demo - discovering and joining domains with realm

Apache module mod_lookup_identity

Apache module mod_lookup_identity

We're not done yet

All your users are belong to us

Herding secrets with Custodia

Herding secrets with SSSD

Suse demo

That's all!

Questions?