Service Integration

Welcome to the Moria2 Service Integration guide. This guide consists of several chapters, which can be read from start to end as a tutorial, or used as a quick reference.

The various chapters can be found in the navigation menu to the left.

Overview and Technologies

First off, let us give a brief run-down on the various technologies and terms used throughout this guide.

Moria2 is the name of the central authentication system described on this site. Its main responsibilities are to perform user authentication, and to relay information about the authenticated user (user attributes) to third-party services. The actual autorization is done entirely by the third-party service based on these user attributes.

A service provides some form of protected content, or service, to end users - relying on Moria2 to perform the necessary authentication. User attributes are passed on from Moria2 to the service. In order to use Moria2, each service needs a registered service account, which basically describes what the service is allowed to do (which attributes it can read, and so forth). If you are considering integrating your service with a particular Moria2 instance, the Moria2 administrator should be able to provide you with the proper service account.

User attributes are not stored in the Moria2 system itself, but on a number of authentication servers. Each authentication server belongs to an organization responsible for maintaining the local authentication server and its content. This is transparent to the service, which need only relate to Moria2.

The communication between Moria2 and a service takes place over ordinary HTTPS, using a message format called SOAP. More information on SOAP can be found here. The interface to Moria2 is described using Web Services Definition Language, or WSDL. There are other details to this communication (JAX-RPC conformance; WS-I Basic Profile conformance) that are well beyond the scope of this guide.

In almost every case, service developers do not need to handle SOAP directly. Instead, a client SOAP library is used to generate stubs from the WSDL. These stubs are then used by the application, hiding the details of SOAP behind a convenient API. Several client libraries exist for various programming languages; the Moria2 project uses Axis for its server- and client-side implementations but any one will do. Please refer to your chosen library for more information.

The Moria2 project also provides a small, but growing number of ready-to-use client libraries, under the common name Mellon2. These should be considered unsupported example code for use at your own risk; the official interface to Moria2 is the WSDL itself, and the proper way to use Moria2 is to generate your own stubs. Please refer to the Mellon2 documentation for further information.

If you wish to start integrating your service with an operational Moria2 installation right away, you may jump to the chapter describing the Moria2 installation run by FEIDE. Otherwise choose a chapter from the navigation menu on your left.