Sorry, you need to enable JavaScript to visit this website.


Your feedback is important to keep improving our website and offer you a more reliable experience.


gSSO or ‘glib-Single-Sign-On’ is an extensible, secure storage and a single sign-on service for Linux-based platforms. Its password and authentication management supports all the common authentication protocols, like OAuth, Digest and SASL out of the box. gSSO is extensible, based on a plug-in architecture.

Applications can use gSSO through lib-signon-glib. Functional flow is described in this chapter.


Identity creation and instantiation

Identity can be instantiated from an existing identity, based on identity id, or created from a given IdentityInfo data. In the case where identity is being instantiated from an existing id, the request is checked against the access control list of the specified id. In the case of a new identity, the creator specifies the necessary access control list.

Establishing a session

AuthSession is instantiated from an Identity instance for a requested method. The requested method is checked against the Identity’s access control list. When the daemon side object instance is created, a plug-in corresponding to the requested method is loaded. All operations are serialized on identity/method basis to avoid overlapping or redundant user interactions.

Session flow

Each operation performed by a plug-in consists of one or more process() calls by a client application, with corresponding response() from the plug-in back to the application. An operation is referred to as a mechanism and related data is passed in a SessionData model as an argument. Each request is checked against the related Identity’s access control list. The plug-in defines the necessary actions required to complete a full cycle of operation(s). This may involve the plug-in performing a user_action_required() call towards the gSSO user interface component, with a corresponding user_action_finished() back to the plug-in. Any number of these user interaction rounds may be performed. User interactions are generally transparent from the requesting application’s point of view, unless it has specifically requested such an interaction be performed. In the case where an interaction would be unsuitable from the requesting application’s point of view, it can deny such interactions. In the case where user interactions were denied by the application, and such an interaction would be required for the requested operation, the plug-in should respond to the request with an error.

Token authentication

This sequence displays the generalized meta-flow of a token authentication session.

token authentication flow diagram

Digest authentication

This sequence displays a standard HTTP digest authentication flow.

HTTP Digest authentication flow


Security context presentation

The security context model uses two layers:

  • The lower layer is called system context, representing a binary executable path on standard Linux and the SMACK label on a SMACK-enabled system.
  • The higher layer is called application context, representing scope inside application.

The two-layer method is designed to allow bindings for scriptable environments, where the runtime may even berunning multiple script contexts within a single process.

Access control

Each stored identity features owner security context information and an access control list. An access control list is [{security context}:{method, [mechanisms, ...]}, ...] mapping. For access checks, system context is first checked against the ACL and platform rules. If the system context check passes, the application context check, against ACL, is performed.