Sequel Security Services¶

The Sequel Security Service is responsible (in part) for providing authentication and authorisation services to Sequel products. It provides three primary capabilities (directly or indirectly)

• Authentication – identifying a user
• Authorisation – identifying a user’s permissions/roles/rights
• User Information - store and cache

Some principles have been applied on the design and development, making Sequel Security Service:

• the single master domain for managing security concerns, shared across all our frontend applications and APIs,
• based on modern and secured standards: oAuth 2.0 and OpenID Connect protocols
• open to connect to other identity providers (aka IdP) systems: Azure, Okta, Jumpcloud,...
• scalable
• cloud ready
• API first

Whilst the Sequel Security Service can perform Authentication & Authorisation capabilities itself, it is typically used as a proxy to identity providers who have responsibility for identifying a user and their permissions/roles/rights. This approach enables Sequel products to leverage the benefits and vendor implementations of multi-factor authentication (MFA), single sign-on (SSO), identity protection & monitoring etc., providing customers with a secure, trusted, tried and tested mechanism to authenticate and authorise users.

Critically, when used as a proxy/middleware Sequel Security Service does not store user credentials (eg username, password), nor does it have knowledge of these sensitive credentials – the responsibility of identifying a user lies with the identity provider (eg Microsoft Azure, Okta,...). At no point are these sensitive credentials communicated, processed or stored by the Sequel Security Service. The Sequel Security Service is responsible for storing non-sensitive user information, within its User Information Store and Cache, and providing this user information to other products within the Sequel suite. Section User Information Store and Cache provides an overview of this functionality embedded within the Sequel Security Service.

Features¶

Authentication as a Service¶

Centralized login logic for all our integrated products; based on Duende IdentityServer, an officially certified implementation of OpenID Connect.

Single Sign-on / Sign-out¶

Single sign-on (and out) over our products.

Auto sign-out on inactive session detection.

Access Control for APIs¶

Issue access tokens for APIs for various types of clients, e.g. server to server, web applications, SPAs and native/mobile apps. Used for protecting our web applications, public APIs, internal communications and also Sequel API Gateway.

Federation Gateway¶

Support for external identity providers like Azure Active Directory, Okta, JumpCloud, Windows Integrated Security, Verisk ISO ClaimSearch and opening federation to other external identity providers.

Single master domain¶

All security concerns like users, permissions, roles, groups,... are centralized in a central service: open via an API and also an SPA Administration site.

Role-based access control¶

A role-base access control model based on the concepts of groups and roles; that models all Sequel's products integrated with the Security Service.

Cross-domain identity management¶

Management and synchronization of cross-domain identity provider is supported; allowing exchange and translate users and permissions from different identity providers to Sequel Security Service and Sequel products. Currently, this is supoprted for Active Directories (with LDAP) and Microsfot Azure (with MsGrpah).

Delegated entities and user management¶

The Entity Delegated feature allows to define entities (team, organizations,...) and delegate the management of permissions of those users.

Import and Export tools and APIs¶

A console tool and an API allows to import and export configurations by domains (authentication, authorization, users, entities,...) and/or applications.

Why¶

At Sequel we are trying to move our applications to an architecture oriented to services, and with great influences from microservices. In this process, we need to decouple services and also improve communications and delegate responsibilities. Regardless to this point security is one of our first challenges.

Our legacy architecture (in terms of security) presented some problems like:

• Security model/technology is not the same across products.
• Security management is not centralized. Users have to be created and managed in multiple applications.
• Security is closed and not based on modern standards.
• Security features are not supported equally across all our products.
• Security is coupling heavily our services.

This is causing us (and to our clients) some problems:

• Duplicated efforts: developing security
• Duplicated efforts: configuring duplicated user accounts for each service.

About how this documentation is organized¶

The documentation has been organised in different sections: