Skip to content

Security SaaS

A new way to deploy Security FVMs, but faster and in containers

User Manual

If you are looking for the User Manual, there is a deditated page for this.

How it works

All instances run in a Kubernetes cluster and data is stored in an external SQL Server VM. Rabbit MQ, instead, is not managed by the platform, and one must be provided at creation. To interact with the platform, an API is available to run basic operations on it.

The API takes care of deploying and destroying the instances when a request is received, as well as to create and destroy the database for the instance. Up, Down, and Upgrade operations are managed through ansible playboks (kind-of scripts) and Helm charts (package manager for Kubernetes), and they runin the background when an operation is requested to run. Each operation is described in Operations section. Below there is a video that explains the create new instance operation:

Deployment structure example

A deployed instance will have 4 services that corresponds to API, Authentication, Authorization and Administration which can only be accessed from inside the cluster. As shown in the above diagram, in which two instances called massanella and puig-major have been deployed. A reverse proxy (represented above as ingress) is used in front of the cluster to carry the external requests to the right container for the requested URL.

Request example to massanella

For example, a user requests access to https://identity.office.sbs/massanella/admin. This request will be received by the ingress controller, then it will break down the URL to extract massanella as instance and admin as the service to connect to. After that, it will deliver the request to the container (in this case the Adminstration one). The container will produce a response and it will deliver it to the ingress controller container, which it will then redirect to the user that made the request. This works for other services and instances by only changing corresponding part of the URL.

Request example to puig-major

In this other example, https://identity.office.sbs/puig-major/api/swagger will send the request to the instance puig-major and api (Security API) container (for that instance), and deliver the response to the user.

Operations

Up (creating an instance)

Behind the scenes, create a new instance consists basically in these steps:

  1. Create the instance database in SQL Server
  2. Create a user for that database
  3. Publish DACPACs (database schemas) to the database
  4. Create the default tenant in Multitenancy database
  5. Fill Security tables with Security Vanilla configuration
  6. Create the admin user
  7. (optional) Fill Security tables with custom Security configurations (like Workflow, Claims, Origin...)
  8. Install Helm chart with specific parameters for the new instance (aka deploy to the Kubernetes cluster)

Down (destroying an instance)

When a destroy request is received, it will do the following steps:

  1. Uninstall Helm release (aka remove deployment from the Kubernetes cluster)
  2. Drop instance database from SQL Server
  3. Drop instance user from SQL Server

Upgrade

This operation can upgrade an instance to a new version, or update the configuration of it (or both). Whatever parameter is changed, the steps it will follow are:

  1. Publish DACPACs (database schemas) to the database - this will update the existing database to the latest schema
  2. Fill Security tables with (updated) Security Vanilla configuration
  3. (optional) Fill Security tables with (updated) custom Security configurations
  4. Upgrade the Helm chart release with the instance parameters (aka update deployment on the Kubernetes cluster)

Housekeeping: Upgrade All

This operation will upgrade a bunch of instances which has no fixed version (aka use always latest version). Internally calls the Upgrade operation for each instance to upgrade.

Housekeeping: Delete expired

Instances can have an expiration date. When this date is reached, this operation will destroy all these expired instances using the Down operation for each.

Get status

This operation allows a user to get information about an instance itself. When information is requested, it will try to read:

  • The deployment status
  • The public/external URLs for each Security service
  • (optional) The logs for each container (dbo.Logs logs are not included here)
  • (optional) The health checks for each service