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:
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 email@example.com) and navigate to your subscription. In the left menu, click on Resource Providers and make sure that the following resources are registered:
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:
qa-slascone-licensing* (if necessary)
Create a new user e.g., firstname.lastname@example.org, 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:
- Directory (tenant) ID
- The client secret value (not the Secret ID)
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 email@example.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.
SIGN IN WITH EXTERNAL IDENTITY PROVIDERS
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
Here an additional article explaining the configuration process.
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 firstname.lastname@example.org 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.
You can set the subdomain/url for the UI and API, for example:
In order to accomplish that, you need to configure the DNS entries accordingly.
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.
Please sign in to leave a comment.