Developer's guide¶

The Sequel Security Service is a system built on the .NET Core stack (among other technologies). This guide describes some useful tips for developers in order to configure the dev box.

.NET Core version¶

The applications of the Sequel Security Service has been implemented using .NET6; Make sure that you have the right version by just running the following command:

> dotnet --version

If the previous command doesn't output a version higher or equal to 6.0, then you should install the .NET Core SDK from https://dot.net.

Local HTTPS configuration for 'dotnet' command¶

The applications that compose the Sequel Security Service must always be running on HTTPS. This is mandatory for production environments, but also for local environments during the development stage. As described in the previous section, ASP.NET Core 6.0 is the current version of the framework that is being used; there's a dotnet global tool built into .NET Core 6.0 to help with certificates at dev time, called "dev-certs." In order to configure the dev certificates for localhost into the machine being used for development the following command should be executed:

> dotnet dev-certs https --trust

A popup asking if the localhost certificate should be trusted will be shown and, after accepting it, then the applications will be executed on HTTPS without issues on Chrome or any other browser. Now the applications can be safely started on HTTPS using:

dotnet run

Local HTTPS configuration for ISS Express¶

When running/debugging the applications from Visual Studio they can be run on IIS Express. The first time you execute the applications a popup will appear to trust the IIS Express dev certificate; by accepting it the applications will run on HTTPS without issues.

Use of a Security FVM for local development¶

This document will guide you on how to configure a Security FeatureVM as a Security server for local development in a team. For this, you need the following:

• Create a Security FVM
• Exported configuration for the application which will use Security (Workflow, Claims, Origin, Impact...)
• Security Tool (see docs)

Create the FeatureVM¶

Just create it. You may use master as source branch. But if you like to be in the edge, you may use dev. The name of the build contains the machine name of the VM (FVMSECXXXXXX.office.sbs).

Install configuration¶

The configuration to deploy in Security of the applications should be tweaked to work on the development machines. For each application, check the Clients.json files to ensure the fields AllowedCorsOrigins have URLs that points to localhost (or localhost.office.sbs - see this) and ensure the ClientSecrets are correct and properly encrypted.

Then run the security tool to deploy the applications:

sequel-security import -c 'Data Source=FVMSECXXXXXX.office.sbs;Initial Catalog=SecurityDatabase;Integrated Security=True;Multi pleActiveResultSets=True;' --domain authentication -a ${APP_KEY} -i /path/to/the/package
sequel-security import -c 'Data Source=FVMSECXXXXXX.office.sbs;Initial Catalog=SecurityDatabase;Integrated Security=True;Multi pleActiveResultSets=True;' --domain authorization -a ${APP_KEY} -i /path/to/the/package

The ${APP_KEY} token is the application's identifier (like WF for Workflow or ORI for Origin) which will try to import in the two commands. This will import Authentication and Authorization configuration for each.

After importing all configuration, an IIS Reset is recommended to clean all caches in Security:

iisreset FVMSECXXXXXX

Give admin their rights¶

By default, an admin user is created with the Feature VM. So, in order to the admin user to access the apps, it must have the right roles. So follow this steps to give it the permissions:

• Go to the Administration panel of security (https://fvmsecXXXXXX.office.sbs/Administration).
• Once there, go to the Users page.
• Select the admin user, which will open a drawer at the right.
• Select the MEMBERSHIP tab and then press the pencil icon near the admin's name (this will change to edit mode).
• Add the roles for each application.

Now you may be able to log in into the application in your local machine.

Change Security URLs in configuration¶

Now it is time to point the apps in the development machine to the Feature VM. Go to the web.config or appsettings.json of your .NET Framework/.NET Core app and change these values as following:

Now, give it a try to see if it is working. Access to the application on your development machine, check if it starts the Authentication Flow, and the app can get the information about the session (aka logged in properly).

The domain and the cookie¶

The session is maintained using a cookie which is available only under the domains that ends with .office.sbs. So, you may need to use localhost.office.sbs for the configuration to ensure the cookie is present in the development machines. To make it work, edit the hosts file (C:\Windows\System32\drivers\etc\hosts in Windows, /etc/hosts on *nix) and add 127.0.0.1 localhost.office.sbs. The use this domain to access to the apps in your machine.