Authentication

Introduction

This document outlines the authentication process within our system, detailing user prerequisites, authentication groups, LDAP configuration, roles, and permissions. Understanding these elements is crucial for managing access and ensuring secure and efficient operation.

User prerequisites

For a user to access the system, two fundamental requirements must be met:

Role Assignment: The user must be assigned a specific role within the system. Active Status: The user's account must be set to active. Organisation Membership: Users must be part of an organisation to access ONAPI Applications.

Roles

Roles represent sets of permissions within Flow, controlling user access and actions within the system. Users with multiple roles inherit highest combined permissions for broader access.

Auth Groups

Users can be divided into groups based on their email address, each auth group can validate it's users against either a LDAP(s) backend or against Flow's internal database.

Active Directory authentication

LDAP authentication involves validating users by their email and password, requiring a group mapped to a role in Flow for access permissions.

LDAP Configuration

Key	Description	Required
AD_BASE	The base for the search. It must be a valid distinguished name, and can't be emtpy	Yes
AD_HOST	The server we want to be connected to.	Yes
AD_PORT	The port the server is listening to.	Yes
AD_BIND	System user used to search for users by email.	Yes
AD_PASS	Password for system user.	Yes
AD_SSL	A true/false flag to tell if it's a SSL connection or not.	No

Roles

LDAP user roles map Active Directory groups to Flow roles, defining system permissions.

Fallback Auth Groups

For critical user access continuity, a fallback auth group can be specified to maintain system access even if primary authentication services are unavailable, assuming users meet Flow's authentication prerequisites.

Permissions

Flow is divided into namespaces, some of which are required for the user to be able to access the system, these are marked with a red label containing the text "required namespace". Namespaces can be marked as no Read/Read & Write or be left unchecked to disabled access for the role. If a role does not have read access certain elements of the GUI will not be rendered, for example if "catalogue/agreement" is disabled users of that role will not be able to see the "Agreements" widget on an Address or Customer.

Administrator

An "Administrator" role grants full read/write access across the system, bypassing specific permissions for streamlined management.