PRIVATE DEPLOYMENT - PREREQUISITES – Help Center | SLASCONE

SLASCONE is a Microsoft Azure (cloud-native) application that can be installed and deployed in one of the following ways:

Private: Using an own/existing Azure subscription. This ensures that you are the master of your data, and you can choose in which region your application and data reside.
SaaS: Everything is managed by us.

In both cases, you don’t have to worry about the installation: this is performed by us.

Due to the fact that SLASCONE is an Azure cloud-native application, it can not be installed as a VM, neither on-premise nor on other cloud platforms such as AWS.

PREPARING YOUR OWN SUBSCRIPTION

When you choose to use an own/existing Azure subscription, an Azure administrator needs to perform the following steps in order for us to be able to install SLASCONE:

SYSTEM LANDSCAPE

We recommend two 2 systems: DEV, PROD, but you can have more than two if necessary. This article assumes that the two systems are installed in the same subscription. However, in case they need to reside in different subscriptions, the process is identical.

REGISTRATION OF RESOURCE TYPES

Certain resource types need to be registered in the subscription. Log in to the Azure portal as a subscription administrator (not as licensing@yourdomain.com) and navigate to your subscription. In the left menu, click on Resource Providers and make sure that the following resources are registered:

microsoft.cdn
microsoft.insights
microsoft.keyvault
microsoft.logic
microsoft.maps
microsoft.operationalInsights
microsoft.sql
microsoft.storage
microsoft.web
microsoft.azureactivedirectory

RESOURCE GROUP CREATION

A resource group contains the resources required to successfully deploy SLASCONE in Azure. It is a container that holds related resources for an Azure solution. Please create new resource groups called:

dev-slascone-licensing

qa-slascone-licensing* (if necessary)

prod-slascone-licensing

USER CREATION

Create a new user e.g., licensing@yourdomain.com, that has owner permissions in the created *-slascone-licensing resource groups.

This user should be able to send (administrative) emails. You will have to provide us the user’s credentials and the smtp server details.

SERVICE PRINCIPAL CREATION

In your Azure Active Directory, register a new application called vsts slascone. Within the registration, you need to create a client secret.

Assign the service principal vsts slascone the contributor role in the created *-slascone-licensing resource groups.

You will have to provide us the following information about the vsts slascone app registration:

Application (client) ID
Directory (tenant) ID
The client secret value (not the Secret ID)

IDENTITY PROVIDER

SLASCONE uses Azure AD B2C as its internal identity provider (idP).

If your subscription already has an Azure AD B2C tenant, it is recommended to use this one. In this case, the user licensing@yourdomain.com has to have administrative rights on this tenant, at least during the installation.
If your subscription does not have an Azure AD B2C tenant, a new one is created during the installation process. In this case, you don't have to do anything.

All stages/sytems (dev, qa, prod) use this Azure AD B2C tenant. You do not need an Azure AD B2C tenant per stage/system.

You can configure Azure AD B2C to allow users to sign in to your application with credentials from social and enterprise identity providers. Azure AD B2C can federate with identity providers that support OAuth 1.0, OAuth 2.0, OpenID Connect, and SAML protocols. For example, Facebook, Microsoft account, Google, Twitter, and AD-FS. You can read more about this topic here.

AZURE ACTIVE DIRECTORY INTEGRATION

You can integrate your company’s existing Azure AD in order to provide a single sign on experience for your internal staff, thus eliminating the necessity for an additional login/password and making sure that your internal user management policies are met. In this case Azure AD acts as the identity provider (idP), while Azure AD B2C acts as the service provider (SP).

In order to achieve that, an Azure AD administrator needs to register an application within your organizational Azure AD. This article explains the process in detail.

You will then have to provide us the following properties of the registered application so that we can configure the Azure AD B2C accordingly:

Application (client) ID
Client Secret
Metadata url

Here an additional article explaining the configuration process.

POST-INSTALLATION STEPS

As part of the initial installation, a service principal is created. The service principal is an administrative (not user bound) login, allowing us to install updates. This means that we do not need the user licensing@yourdomain.com anymore. This is crucial if you want to restrict any kind of access to your subscription (resource group) through the Azure Portal, ensuring that no employee outside your organization (including us) has access.

SUBDOMAIN CONFIGURATION

You can set the subdomain/url for the UI and API, for example:

licensing-api.yourdomain.com
licensing-ui.yourdomain.com
dev-licensing-api.yourdomain.com
dev-licensing-ui.yourdomain.com

In order to accomplish that, you need to configure the DNS entries accordingly.

UPDATES

When using your own Microsoft Azure subscription, you can choose whether we are allowed to install updates with or without your prior consent. This configuration might involve different steps for DEV, QA and PROD, e.g., we are allowed to install updates in DEV and QA without consent, and in PROD only with your explicit prior consent.