Authentication Providers

When you log in, an auth provider checks your credentials to make sure you are an authorized user.

Configuring auth providers

Authentication providers are configured in your configuration.yaml under the openpeerpower: block. You can supply more than one, for example:

openpeerpower:
  auth_providers:
    - type: openpeerpower
    - type: legacy_api_password
      api_password: !secret http_password

Available auth providers

Open Peer Power auth provider

This is the default auth provider. The first user created is designated as the owner and can create other users.

User details are stored in the [your config]/.storage directory. All passwords are stored hashed and with a salt, making it almost impossible for an attacker to figure out the password even if they have access to the file.

Users can be managed in Open Peer Power by the owner. Go to the configuration panel and click on Users.

This is the entry in configuration.yaml for Open Peer Power auth:

openpeerpower:
  auth_providers:
    - type: openpeerpower

If you don’t specify any auth_providers section in the configuration.yaml file then this provider will be set up automatically.

Trusted Networks

The Trusted Networks auth provider defines a range of IP addresses for which no authentication will be required (also known as “whitelisting”). For example, you can whitelist your local network so you won’t be prompted for a password if you access Open Peer Power from inside your home.

When you log in from one of these networks, you will be asked which user account to use and won’t need to enter a password.

Here is an example in configuration.yaml to set up Trusted Networks:

openpeerpower:
  auth_providers:
    - type: trusted_networks
      trusted_networks:
        - 192.168.0.0/24
        - fd00::/8

Trusted Users Examples

openpeerpower:
  auth_providers:
    - type: trusted_networks
      trusted_networks:
        - 192.168.0.0/24
        - 192.168.10.0/24
        - fd00::/8
      trusted_users:
        192.168.0.1: user1_id
        192.168.0.0/24:
          - user1_id
          - user2_id
        "fd00::/8":
          - user1_id
          - group: system-users

First note, for trusted_users configuration you need to use user id, which you can find through Configuration -> Users -> View User Detail. The trusted_users configuration will not validate the existence of the user, so please make sure you have put in the correct user id by yourself.

Second note, a trusted user with an IPv6 address must put the IPv6 address in quotes as shown.

In above example, if user try to access Open Peer Power from 192.168.0.1, they will have only one user available to choose. They will have two users available if access from 192.168.0.38 (from 192.168.0.0/24 network). If they access from 192.168.10.0/24 network, they can choose from all available users (non-system and active users).

Specially, you can use group: GROUP_ID to assign all users in certain user group to be available to choose. Group and users can be mix and match.

Skip Login Page Examples

This is a feature to allow you bring back some of the experience before the user system was implemented. You can directly jump to main page if you are accessing from trusted networks, the allow_bypass_login is on, and you have ONLY ONE available user to choose in the login form.

# assuming you have only one non-system user
openpeerpower:
  auth_providers:
    - type: trusted_networks
      trusted_networks:
        - 192.168.0.0/24
        - 127.0.0.1
        - ::1
      allow_bypass_login: true
    - type: openpeerpower

Assuming you have only the owner created though provisioning process, no other users ever created. The above example configuration will allow you directly access Open Peer Power main page if you access from your internal network (192.168.0.0/24) or from localhost (127.0.0.1). If you get a login abort error, then you can change to use Open Peer Power Authentication Provider to login, if you access your Open Peer Power instance from outside network.

Command Line

The Command Line auth provider executes a configurable shell command to perform user authentication. Two environment variables, username and password, are passed to the command. Access is granted when the command exits successfully (with exit code 0).

This provider can be used to integrate Open Peer Power with arbitrary external authentication services, from plaintext databases over LDAP to RADIUS. A compatible script for LDAP authentication is this one, for instance.

Here is a configuration example:

openpeerpower:
  auth_providers:
    - type: command_line
      command: /absolute/path/to/command
      # Optionally, define a list of arguments to pass to the command.
      #args: ["--first", "--second"]
      # Uncomment to enable parsing of meta variables (see below).
      #meta: true

When meta: true is set in the auth provider’s configuration, your command can write some variables to standard output to populate the user account created in Open Peer Power with additional data. These variables have to be printed in the form:

name = John Doe

Leading and trailing whitespace, as well as lines starting with # are ignored. The following variables are supported. More may be added in the future.

• name: The real name of the user to be displayed in their profile.

Stderr is not read at all and just passed through to that of the Open Peer Power process, hence you can use it for status messages or suchlike.

Legacy API password

Activating this auth provider will allow you to authenticate with the API password set in the HTTP component.

openpeerpower:
  auth_providers:
   - type: legacy_api_password
     api_password: !secret http_password

api_password is required option since 0.90 release.

Activating this auth provider will also allow you to provide the API password using an authentication header to make requests against the Open Peer Power API. This feature will be dropped in the future in favor of long-lived access tokens.

If you don’t specify any auth_providers section in the configuration.yaml file then this provider will be set up automatically if api_password was configured under http section.