1 Setup Dev ENV for Cargo
2 Release to Production
- - 2.1.1 Determine Publish Date with Product Owner
  - 2.1.2 Timelines
  - 2.1.3 Create Change Request
  - 2.1.4 Create release package - DevOps
  - 2.1.5 Create release package - Visual Studio
- 2.2 Create Azure App Registration for MITRACK access to shared API Services
3 Setup Access from .NET Core Web App MVC running Windows Authentication to Azure AD Authenticated Service in Cloud
- 3.1 Add application role to target cloud service app registration.
- 3.2 Set up authentication in a client application
  - 3.2.1 403 Forbidden result may be returned if an authorization scope is set on the controller or action method.

Setup Dev ENV for Cargo

Configure IIS Authentication to enable Windows Authentication for MITRACK application

Release to Production

Determine Publish Date with Product Owner

It is important to plan ahead in order to allow enough time to create change requests, complete tasks, lock down code, and create publish package for the release.

Timelines

Change Request ticket must be created (In SMGC or ORION) by noon on the Wednesday preceding the week of the release date.
Code must be locked down by end of day the Thursday of the week preceeding the release week
Publish package must be uploaded to staging folder by noon on Friday of the week preceeding the release week.

Create Change Request

Create a ticket in current system for web team to perform software change in the MITRACK application. For SM-GS, see instructions here or here

Create release package - DevOps

On the day of the lockdown, on or before Thursday of week prior to release week, locate the MITRACK-Release-CI pipeline. Select the Branches, Tags, or Commits tab, and select the target value in the list below.
MITRACK-Release-CI pipeline. Select release branch and run pipeline
Click Run to run the MITRACK-Release-CI pipeline. There is no script to update the version number of the application in this pipeline so whatever release was last set in the application is what will be released. It is recommended to name the release branch with the version number in the name for simplicity.
Once the job is run, click the last run and open the job.

Open and download the artifact.

Save it to a location on your computer.
Extract and inspect contents of artifact. This is the publish package.
Update web.config set environment variable to “Production”.
Upload this package to the staging folder specified in the SM-GS ticket for the web team to deploy on release date.

Create release package - Visual Studio

On the day of the lockdown, on or before Thursday of week prior to release week, in DevOps locate the commit history of the dev branch. Verify that all the commits to be released are in, note the latest version number.
Create a new branch off dev with name releaseX.X.XXXX.X where X.X.XXXX.X is the latest version number in the commit history.
Locate the new branch in Visual Studio Git Changes and checkout it locally.
Unknown Attachment
Uncomment the version sync post build event, build project, and comment it out again. This updates version number of 4 project files. Verify that files ~\wwwroot\script\Mitrack.X.X.XXXX.X.js, ~\wwwroot\script\Mitrack.1.1.2411.0.min.js, ~\Views\Shared_Layout_en.cshtml, ~\Views\Shared_Layout_fr.cshtml are all updated to the latest app version.
Unknown Attachment
In VS Solution Explorer, right-click project name and select Publish. Create publish profiles for each environment if they do not already exist. Only Production profile is required for this procedure.
Unknown Attachment

From Project Properties folder, locate and open Production.pubxml profile file and specify a location on local machine, and ensure the EnvironmentName tag is present and is set to Production.
Unknown Attachment
Click the Publish button to publish project to specified location. Verify that publish succeeded. Commit changes and push to remote. Do not merge to dev branch. This is the release branch, and should be available for release should the published files be damaged or lost.
Zip the published files and upload to staging folder specified in SM-GS ticket.

Create Azure App Registration for MITRACK access to shared API Services

This setup is useful for an application set up to use Microsof t Identity Platform authentication. MITRACK uses windows authentication. Please see below for instructions for such scenario.

MITRACK needs to be registered with Azure Active Directory Identity system for access to shared API services like

Document Management Service
List of Values Service
Workflow Management Service

Registrations needs to be created for each DEV, TEST and PROD environments.

Please follow Microsoft Documentation here on how to create this. Use the NCD MITRACK Web Client DEV registration as an example.

Additional info can be found here

Samples and further documentation can be found here

Setup Access from .NET Core Web App MVC running Windows Authentication to Azure AD Authenticated Service in Cloud

The MITRACK application is a .net core web application which utilizes Windows authentication and needs to access services running in Azure cloud using the Microsoft Identity Platform authentication (aka Azure AD)

To set up this authentication to work, follow these steps:

Add application role to target cloud service app registration.

From Azure portal home page, locate and click on Azure Active Directory. This should open the TC/TC tenant active directory. Note the Tenant ID to be referenced later. Click App registrations on the left panel.

Click All applications and use the filter box to search by application name. Click to load app registration.

Copy the Application (client) ID and Directory (tenant) ID values for the application. The tenant id should match value from azure active director described earlier.

Click Certificates & secrets. Click New client secret enter a descriptioand expiry time and click Add.

Copy and save the value of the secret in a secure place. This value is displayed once.

Click App roles on the left. Click Add role, fill out the form and save. Note the display name and value.

Click API Permissions on the left. Click Add a permission, click APIs my organization users and search with app registration name. Click to load app and reveal roles.

Click Application permissions and check box next to role created previously.

The added permission will show up in the list of permissions for app registration: An admin consent is required for app applications since they are not delegated. Contact an administrator fromt he Cloud group to provide consent.

Set up authentication in a client application

The authentication parameters have to be sent from the calling application, to be used to obtain an access token which is passed in a request header to authenticate for access to cloud service:

In appsettings.json file, add the following keys and values. This is to by used by the IConfiguration interface to obtain values in code. Values can be hard-coded for a quick test as well.

"AzureAd": {
"Instance": "https://login.microsoftonline.com/",
"TenantId": "[Tenant ID]",
"Audience": "https://034gc.onmicrosoft.com/ncd-dms-dev"
},
"DocumentService": {
"BaseUrl": "[Base url of target service]",
"ClientId": "[Client ID]",
"ClientSecret": "[Client secret value]"
},

In startup class, register a HttpClient for the service:

services.AddHttpClient("DocumentManagementService", c =>
{
c.BaseAddress = new Uri(_configuration.GetValue<string>("DocumentService:BaseUrl"));
}).AddHttpMessageHandler<HttpRequestLoggingHandler>();

To call this service, create the client and pass auth credentials in as shown:

_clientFactory = clientFactory;
_client = _clientFactory.CreateClient("DocumentManagementService");
_config = config;

        // access token
        AuthenticationResult? result = null;
        IConfidentialClientApplication app;
        string tenantId = _config["AzureAd:TenantId"];
        string resource = _config["AzureAd:Audience"] + "/.default";
        string instance = _config["AzureAd:Instance"];
        string clientId = _config["DocumentService:ClientId"];
        string clientSecret = _config["DocumentService:ClientSecret"];
        app = ConfidentialClientApplicationBuilder.Create(clientId)
            .WithClientSecret(clientSecret)
            .WithAuthority(new Uri(instance + tenantId)).Build();
        string[] ResourceIds = { resource };
        result = app.AcquireTokenForClient(ResourceIds).ExecuteAsync().Result;
        _client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", result.AccessToken);

Client object can be used to call the service as below:

var response = await _client.GetAsync(Uri.EscapeDataString($"Anonymous/v1/documents/environment"));

403 Forbidden result may be returned if an authorization scope is set on the controller or action method.

Controller:
[RequiredScope(RequiredScopesConfigurationKey = ScopePolicy.ReadWritePermission)]
public class DocumentsController : DocumentBase

Method:

[Authorize(Policy = RolePolicy.RoleAssignmentRequiredWriters)]
public new IActionResult UploadDocument([FromBody] UploadedDocumentsDTO uploadedDocumentsDTO)

These would have to be removed for access to be granted for a client application set up this way. An ‘anonymous’ controller could be created to inherit from a base controller, or a service layer could be introduced to facilitate this. See GitHub - tc-ca/DocumentService: Microservice on creating, updating, and deleting documents. for an example implementation of controllers.

Marine

MITRACK Web - How Tos