Introduction

For security and flexibility reasons, authentication sessions in GSSO are performed by authentication plugins that run in separate processes and communicate with the GSSO daemon using D-Bus IPC. This page describes that IPC, and the options that plugin writers have for implementing additional plugins.

GLib plugins

The standard, most simple way to write plugins is by using GLib to implement GSignondPlugin interface, package the code as a shared library, and install the library into gsso's standard location for GLib plugins. This approach is described in detail in GSignondPlugin chapter.

Plugin loaders

If using GLib to implement authentication plugins is undesirable or impossible, you can provide a binary that implements a GSSO plugin loader, which should be installed in pkg-config gsignond --variable=pluginloadersdir.

The GLib plugin loader that manages GLib-based plugins is a reference implementation for such a loader. It is possible to fork and tweak its code (as long as the IPC protocol, described below, is preserved), or it's also possible to write such a loader from scratch. The source code for the GLib plugin loader can be found here.

Plugin loaders' command line options

The plugin loader binary should implement the following command line options:

  • --list-plugins command line option must be supported. The plugin loader binary should then list available plugin names, one name per line, for example:


                        > gsignond-plugind --list-plugins
                        password
                        ssotest
                        digest
                        

    NOTE: it is recommended that plugin names are either hardcoded in the plugin loader, or determined from plugin filenames in the filesystem. It's less secure to determine the names by loading the plugins' code and calling into each plugin.
  • --load-plugin=name command line option must also be supported. The plugin loader binary should then load and prepare the plugin with the corresponding name (or simply prepare the plugin that is provided within the plugin loader itself), and export a d-bus object on standard input and output streams that gsso daemon will communicate with. The next session describes this in more detail.

Plugin loaders' D-Bus IPC

When run with a --load-plugin command line option, the plugin loader process is expected to export a D-Bus object on path "/" that implements this interface.

The interface declarations map directly to the plugin API. See GSignondPlugin interface for the meaning of various methods, signals and properties.

The object is exported on a connection that is formed from standard input and standard output streams. This is the most secure way to communicate with the gsso daemon, because these streams are visible only to the two ends of the connection - the plugin loader process and the parent process (the gsso daemon).

NOTE: at the moment input and output should happen on two separate streams, the standard input and the standard output respectively. In the future, gsso will set both streams to the same bidirectional channel, for compatibility with D-Bus' unixexec transport.