|
|
|
|
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.
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.
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.
The plugin loader binary must implement the following command line options:
--list-plugins.
When called with this option the plugin loader binary should list
available plugin names, one name per line. Plugin names must
contain only ASCII alphanumeric characters or one of '.', '_' or '-'
(dot, underscore or dash). This set is known as POSIX portable
filename character set. For example:
> gsignond-plugind --list-plugins
password
ssotest
digest
--load-plugin=name. When called with
this option, the plugin loader binary should
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.
--plugins-watch-path. This option is used to (optionally) support
dynamic update of plugin lists without having to restart the daemon. When
called with this option, the plugin loader should print on the standard output
a path in the filesystem. The daemon will watch this path for changes using inotify,
and when a change is detected, it will ask the plugin loader to list the plugins again
and will update its internal structures accordingly. The plugin loader can also
print nothing, in which case there will be no dynamic update of available
plugins provided by this loader.
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.