An open API service indexing awesome lists of open source software.

https://github.com/wisdom-oss/service-user-management

👥 user and permission management using OpenID Connect
https://github.com/wisdom-oss/service-user-management

backend

Last synced: 6 months ago
JSON representation

👥 user and permission management using OpenID Connect

Awesome Lists containing this project

README

          



User Management


service-user-management


👥 user and permission management using OpenID Connect


Go Lang Version

Open
<br />API Schema Version

> [!IMPORTANT]
> This microservice depends on an external OpenID Connect Provider

This microservice acts as a middle-man between the OpenID Connect Provider used
for authentication of users and the permission management inside the WISdoM
platform to minimize the amount of customization required in a OpenID Connect
Provider.
It accepts the authentication codes generated by the OpenID Connect Provider
and uses them to request an ID Token from the provider.
This ID token is then used to provide an access token which allows
authenticating with backend services and allows dynamically showing and hiding
entries in the frontend.
The user management service uses signed JWTs to ensure that no tampering can
happen on the client side to gain access to services without proper
authorization.

## Configuration
The microservice requires access to a PostgreSQL database for storing the
external identifiers of users and for persisting permission information about
the users.
To connect the microservice to a database, please set the following environment
variables:
- `PGUSER`
- `PGPASSWORD`
- `PGHOST`
- `PGDATABASE`

and if necessary:
- `PGPORT`

Furthermore, you need to specify the client id and secret for the OpenID Connect
provider as well as the issuer as shown in your provider using the following
environment variables:
- `OIDC_CLIENT_ID`
- `OIDC_CLIENT_SECRET`
- `OIDC_ISSUER`
- `OIDC_REDIRECT_URI` — The URI to which a request should be redirected to if it started in the frontend

The required certificates are automatically generated during the initial startup
and stored in the microservice.
It is recommended to create a volume mount if using docker to persist the
certificates during container recreation to ensure updates to not break already
running sessions

## Usage
To use the User Management, just navigate to the `/login` endpoint and the
service automatically redirects you to the configured OIDC provider and sets
the redirect URI according to the configuration.

> [!IMPORTANT]
> If the redirecti uri isn't the service itself, you need to take additional
> steps to retrieve a token set. Using the built-in callback page _isn't
> recommended_ as the flow may appear unnatural for users.
>
> Read more here: [Using an external callback page](#using-an-external-callback-page-recommended)

### With the built-in callback page

>[!NOTE]
> The built-in callback page should only be used while developing and testing
> of the service as it may break the login flow otherwise

The built-in callback page automatically redirects users to the token endpoint
at which a new token set is generated and sent back.

### Using an external callback page (recommended)
If you're using an external callback page, the OIDC provider redirects the
users to the one specified by you.
The provider will add the following query parameters to the redirection which
you need to request a new token set:
- `code`
- `state`

Please use those query parameters and the according values and request a new
token set using the `/token` endpoint as indicated in the
[api documentation](openapi.yaml)