discourse-ekklesia

Discourse plugin for integration with the Ekklesia eDemocracy platform.

Features:

• OAuth2 login via Ekklesia's identity server
• automatic group / trust level assignment for users identified by the id server
• pushing motions to the Ekklesia portal ("Antrag stellen")

Planned Features:

• support for multiple id servers
• more configuration options, some server URLs are still hard-coded
• ... more to come

Installation

Production

For a standard docker installation:

Add to following line to the hooks section in your discourse container config:

- git clone https://github.com/dpausp/discourse-ekklesia.git

Rebuild the docker container:

./launcher rebuild my_image

Dev

Clone the plugin repository to your discourse plugin dir and restart:

git clone https://github.com/dpausp/discourse-ekklesia.git 

Configuration

Everything can be configured in the Discourse admin area. You must at least set the client ID, client secret and the URL of the Ekklesia ID Server.

How Authentication Works

The plugin integrates with Discourse's OAuth2 login mechanism. Discourse creates user accounts for users logged in via the ID server but doesn't store the password. Users can choose an email address in the sign-up process which doesn't have to be identical to the one used on the ID server. Discourse uses the OAuth2 grant type "authorization code". The authorization code from the ID server is used to request an access token. The access token authorizes Discourse to access user-related content on the ID server. See https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2#grant-type-authorization-code for more OAuth2 details. Discourse is the "client" in our case.

Unique users are identified by the AUID which is generated by the ID server. Each application gets its own AUID.

Flow

• User clicks "Login" in Discourse
• User selects "Login via ID server" (is skipped when only one authentication method is available)
• User is redirected to ID server login form
• User enters ID server credentials and logs in
• ID server redirects to Discourse callback URL and passes authorization code to Discourse
• Discourse requests the access token with the client secret, client id and authorization code
• Discourse requests the AUID from the ID server (with access token)
• Discourse shows the signup form to the user if the AUID is not found in the Discourse database

Expected ID server data structures

Example:

# GET /api/v1/user/auid
# (JSON)
{"auid": "39219407-03ae-49ee-b71c-3e837eecaf48"}

# GET /api/v1/user/membership
{"type': "eligible user"}

• auid is a (random) UUID
• type is one of
  • "system user": user created manually on the ID server (used for ID server admins)
  • "guest": guest user that has registered on the ID server which is not a member of the organisation
  • "plain user": is a member of the organisation
  • "eligible user": in addition to "plain user": is eligible for voting