Azure Virtual Network(Azure VNet)

Tags

, ,

Azure VNet is a representation of network in the cloud and is a logical isolation of Azure Cloud dedicated to subscription ability to fully control IP Address blocks, DNS settings, security policies and route tables.

VNet can be further segmented into subnets, each subnets will have a logical collection of Virtual Machines. VNets are completed isolated from one another and this provides the ability to create disjoint networks for development, testing and production that use the same CIDR(Classless Inter-Domain Routing) address blocks. In order to connect VNet to on-premise data center we can use site-to-site VPN connection or Express Route connection. 

It is important to note that before creating Virtual Machines and installing software first plan VNet. This is because an existing virtual machine CANNOT be added to a newly created virtual network.

This article will go through the steps involved in creating a VNet having SubNets and AzureVM’s attached to different SubNet(s). The topology for the sample lab set up is as per below:

Capture

The artifacts in the above diagram include:

VNet: iDynamics-VNet

SubNet(s):

  • FrontEnd-SubNet containing Azure VM resource AZ-FE01
  • BackEnd-SubNet containing Azure VM resource AZ-BE01
  • Management-SubNet containing Azure VM resource AZ-MGMT01

All AZure VM’s can be configured to be accessed through RDP connection by allowing traffic through port 3389. Best practice is to have a Management SubNet with an VM allocated so that external users login to that Virtual Machine and proceed from there on.

There are two addresses associated to each VM viz., Public IP Address and Private IP Address. All the VM’s in the SubNet that need to be accessed from internet need to have Public IP Address. For internal communication between resources in a virtual network Private IP Address is needed.

For setting up the lab the following IP Addressing scheme will be used:

Capture1

Creating Azure Virtual Network (VNet):

Logon to AzurePortal  and search Virtual Networks

Untitled1

Choose Add

Untitled2

Enter the Resource Group and Name

Untitled3

Untitled4

 

Allocate the IP Address

Untitled5

After allocating the IP Addresses 10.0.0.0/16 proceed to add the SubNets as per the table.

Untitled6

Untitled7

Untitled8

Click on Review + Create once all the SubNets are created.

Untitled9

Once successfully deployed

Untitled10

In the next article we will look at creating Azure resources within the various SubNets.

 

 

 

 

 

Generating EarlyBound CRM Entities using Spkl Task Runner

Tags

,

In article we looked at how connection to CRM On-Premise can be established using Spkl  Task Runner. For developing Plugins, Workflows it is a common  to have early bound classes. CrmSvcUtil.exe facilitates generating early bound classes the same can be achieved using Spkl Task Runner.

The batch file earlybound.bat will create the *.cs files as per settings defined in spkl.json file

Untitled1

As per the settings defined the following will be expected output when earlybound.bat is run:

  • A single file name SbmaEarlyBoundTypes.cs containing definitions for entities specified
  • Namespace for the various classes will be SBMA.Crm.Entities
  • One *.cs file will be generated for every entity because of the setting “oneTypePerFile : true”, this can be set to false if the preference is work with only one *.cs file for all the entity type definitions

Right Click on the spkl folder and bring up the command prompt (if using VS 2019  install the extension Web Essentials 2019 so the command prompt can be launched from Visual Studio IDE)

Untitled3

Untitled2

Now run earlybound.bat

Untitled4

Untitled6

The created types is as highlighted below:

Untitled7

 

 

 

 

 

Solution Management

Tags

,

A xRM application built on Dynamics CRM platform consists of several components viz.,

  • Schema: Entities,Relationships between Entities, Option Sets
  • User Interface: SiteMap, Web Resources, Application & Entity Ribbons
  • Anlaytics: Reports, Dashboards
  • Code: Workflows, Plug-ins
  • Security: Roles (built-in and custom), Field Security profile
  • Templates: E-mail, Articles

The above can be packaged up as Unmanaged or Managed solutions so it can be deployed in the target environment.

Managed Solution: A self contained packaged  that can be installed/uninstalled in target environment. No ability to add/remove solution components, changes can made to solution components if already set through managed properties.

Unmanaged Solution: An unmanaged solution provides the ability to add/remove components, delete components (custom entities etc). All the components in unmanaged solution will be references to customizable components in the CRM organization.

When both unmanaged and managed solutions are imported into an organization, conflict resolution is done through Merge and Top Wins stragety

Merge: Applies to user interface components and unmanaged customizations will be last to be applied.

Top Wins: Applies Entities,Views, Security Roles. In case of managed solution the last managed solution imported will have the changes applied and on of this when an unmanaged solution is imported then previous changes are overwritten.

Example:

Consider a solution having “account” entity

solutionlayering1

solutionlayering2

Create two versions using “Clone a Patch” option to change the label on the Account form.

solutionlayering3

solutionlayering4

Change the Phone number label text for the above solution

solutionlayering5

Publish the changes and the Account form view will be:

solutionlayering6

Now create another Clone to Patch version 2:

solutionlayering7

solutionlayering8

The view of Account form after publishing the changes note this is the last Unmanaged Solution to be published.

solutionlayering9

OAuth and OpenID Connect using IdentityServer

Tags

, , ,

In article  we looked at use of JSON Web Token (JWT) for authentication with that foundation knowledge in place in this article we look at IdentityServer4  that provides end points for OpenID Connect (for authentication) and OAuth 2.0 (for authorization) to ASP.NET Core application.

Common protocols used for Authentication include SAML, WS-Fed, OpenID Connect. OpenID Connect in combination with OAuth 2.0 is designed for API. The following table highlights the differences between OpenID Connect and OAuth 2.0

 

OpenIDConnect

For a good example of authentication using OpenID Connect refer to article where we looked at providing login mechanism to Power Apps Portal through Open ID Connect using Google as Identity Provider, a capture or network traffic is as per below:

OpenIDConnect1

In the highlighted content the following will refer to OpenID Connect protocol

  • id_token is returned in JSON Web Token format
  • scope=openid is used for authentication

Being Authentication only framework what OpenID Connect does not do is provide access to the resources in the application and this is where Authorization Framework (Delegated Authorization) based on OAuth 2.0 protocol comes into effect.

The table highlighted some of the terms used in OAuth 2.0 to understand it better we will build an sample application for the following scenario the sample source code is at Git:

OpenIDConnect2

  1. Clients sends a request for authorization token from Secure Token Service (STS) API that has a reference to Identity Server4.
  2. The token presented to the client from STS will be in JSON Web Token format.
  3. The JSON Web Token with will be passed to the Web API method
  4. Dataset will be returned to the client.

The process of granting Client application to call the methods within WebAPI is commonly referred to as a OAuth flow and involves the steps involved in granting consent (permission) to invoked the methods in WebAPI

The sample code solution structure has the following highlighted projects:

OpenIDConnect3

 

IdentityServer(SecureTokenService)> SEIS.IdentitySrv

WebAPI > SEIS.Registration.Api

Client > ConsoleAppClient

An understanding of ADFS concepts will be helpful, the steps described below are synonymous to setting up relying party trust in ADFS.

Step 1: Build and Configure Secure Token Service 

ASP.NET Core provides built in DI (Dependency Inject) and this capability is used to set up STS.

OpenIDConnect4

IdentityServer needs to have following information

  • Clients trying to access WebAPI
  • List of API end points IdentityServer is trying to secure

In our sample scenario they will be ConsoleApp (Client), RegistrationAPI. The plumbing  code will be in Startup.cs

OpenIDConnect5

Config.GetAllApiResources() and Config.GetAllClients() will have pointers to WebAPI and ConsoleApp Client respectively

OpenIDConnect9

This will setup STS with known clients and API resources

Step 2: Build WebAPI and configure to use STS

Using DI (dependency injection) in Starup.cs specify the Secure Token Service (STS) under ConfigureServices method

OpenIDConnect6

Now indicate to use authentication

OpenIDConnect7

The above will set up API to accept access token from STS.  To add permissions to Controller method(s) we need to add Authorize attribute

OpenIDConnect8

Step 3: Build ConsoleApp to request AccessToken from STS before invoking WebAPI methods

The first step for ConsoleApp client will be to request AccessToken from STS and then pass the token using SetBearerToken method of HttpClient object before calling the WebAPI methods

OpenIDConnect10

Result of ConsoleApp client

OpenIDConnect11

The access_token issued by STS confirms to JSON Web Token Format (reference) decoding this at jwt.io will show the following result

OpenIDConnect12

 

 

 

 

WebApi Testing Swaggerui

In article we looked at configuring Swagger UI in ASP.NET Core application, this article looks at using postman and Swagger UI for testing debugging Web API. The sample source code  can be found in Git and for demonstration purposes will be using SEIS.Registration.Api project.

Swagger UI:

From the sample source set SEIS.Registration.Api as start up project and the UI rendered in IIS Express will be as shown below:

swagger

We will debug two API methods viz., POST to Create a Record and GET to Read/Retrieve a Record

To validate the end points for both POST and GET methods are accessible ensure that there is a HTTP Status Code of 200

swaggerget

swaggerpost

Testing POST (aka Create Record)

Run the API project in Visual Studio and attach the Swagger UI process via Debug > Attach to Process 

swaggerpost1

Add the values in the Request under Post and click on Execute

swaggerpost2

The debugging step within Controller method and the Model passed in can be seen as below:

swaggerpost3

After creating record with POST method, debugging the GET method will display the record created.

swaggerget1

swaggerget2

In the next article we will look at using postman for debugging WebAPI.

 

Service Accounts with AD Group Membership for Dynamics installation

In the article we looked at defining GPO for setting up Dynamics CRM platform. The various service account(s) required for the installation of CRM platform will map to the AD groups as per the table below:

Service Account AD Group Membership
svc-crm-app svc-crm-app
svc-crm-async svc-crm-async
svc-crm-deploy svc-crm-deploy
svc-crm-install svc-crm-install
svc-crm-monsrv svc-crm-monsrv
svc-crm-sbox svc-crm-sbox
svc-crm-vss svc-crm-vss

For SQL Instance the AD group membership(s) for SSRS, database is as per table below:

svc-sql-agent svc-sql-agent
svc-sql-database svc-sql-database
svc-sql-reporting svc-sql-reporting

 

 

 

 

Running WebAPI in IIS Express ASP.NET Core 3.0

Tags

,

While creating Web API project targeting ASP.NET Core 3.0 using the template the following the settings in launchSetting.json file

IISExpress

Given iisExpress was selected as hosting platform the expectation is that the end point is accessible in the browser, but instead received the following:

IISExpress1

The error is referring to a setting in IIS even though the WebApi is configured to run under IIS Express within Visual Studio IDE. The solution will be to open Configuration Editor in IIS and set Impersonate t= False as indicated below

IISExpress2

 

Navigate to system.web/identity and set impersonate = false and restart IIS

IISExpress3

The WebApi should now be accessible in the browser

IISExpress4

 

 

 

 

Illustrative sample of Authentication using JSON Web Token(JWT)

Tags

, ,

In the article we looked a aspects of authentication/authorization frameworks that can be used in COTS and bespoke applications. This article will look at Web API authentication using JWT. The sample source code can be obtained from here

The sample code will demonstrate the following scenario

JWTSample1

The User data-model used in the sample application has the attributes as per table below

JWTSample

 

  1. Console App will invoke a post request with username and password to Gateway Api based on Ocelot api gateway and works well for Microservices architecture.  In architecture pattern consisting of several microservices, ocelot provides a simple configurable end point to communicate with each microservice.

JWTSample2

 

“/authentication/authenticate” > pointer to authentication controller and authenticate method within the microservice Web API. 

The JSON file for Ocelot API will consists of ReRoutes specified as a combination of DownstreamPathTemplate and UpstreamPathTemplate.

JWTSample3

The output of the Console App will be as per below, the returned JWT token will be in the format [Header].[Payload].[Signature]

JWTSample4

If we decode the JWT token in the debugger at jwt.io we will get the user information.

JWTSample5

JWTSample6

 

A Comparison of Authentication and Authorization Frameworks

Tags

, ,

To provide Single Sign On (SSO) mechanism for users different authentication frameworks are in place viz., WS-Federation (WS-Fed), SAML, OAuth, Open ID and OpenID Connect.

WS-Fed and SAML (Security Assertion Mark-up Language) are still in use in corporate networks to allow users to connect to COTS (Commercial off the Shelf) products and bespoke applications. Federation (aka delegating authentication/authorization) is achieved using Active Directory Federation Services (ADFS) installed and configured on Windows Server OS.

The three essential components of federation are:

  • Sign-in protocol > What is the mechanism to access the application
  • Authentication protocol > How the user is verified
  • Token Type > Once the user validated what is returned back to the user after successful identification

In the article configuring Dynamics CRM platform for Claims Based Authentication was discussed. Let us look at capture of traffic in Fiddler to see what information gets passed on in Request and Response.

Request

Fiddler

As highlighted accessing https://crm.idynamics.dev/seis will route the request to https://adfs.idynamics.dev containing the following parameter(s)

wa=wsignin1.0 > Indicates ADFS service to invoke login

wtrealm=https%3a%2f%2fcrm.idynamics.dev%2f > Client application using ADFS service

wctx=rm%3d1%26id%3da33a2f6c-768e-48aa-9c3c-b594ef0f60b5%26ru%3d%252fseis%252fdefault.aspx%26crmorgid%3dfa61533b-ea52-ea11-83b5-0017fb000002 > Session data sent back

wct=2020-02-20T09%3a53%3a23Z > Time the application is accessed

wauth=urn%3afederation%3aauthentication%3awindows > Mode of Authentication

Response

Fiddler1

The response will confirm to SAML 1.1 as per specification and the following will be included as part of the “wresult” urn:oasis:names:tc:SAML:1.0:assertion

OAuth/Open ID/ OpenId Connect essentially use JWT (JSON Web Token).

JSON web token stores user information viz., id, permission set (aka claim rules) etc., in a compact format so information can be transmitted securely between client and server. The token will in the form of a string will be digitally signed using HMAC algorithm or RSA.
Available security algorithms are defined as constant string values in SecurityAlgorithms class of Microsoft.IdentityModel.Tokens namespace and in the sample project demonstrating Authentication using JWT we will be using HMAC algorithm.
JWT structure will consists of three parts [Header].[Payload].[Signature] represented as Base64-URL string
Header: A combination of token type + signing algorithm identified by claim set
typ (for token type) and alg (for signing algorithm) represented in JSON format this would look like the one below:

{
“alg”: “HS256”,
“typ:”JWT”
}
Payload: Consisting of claims about the user. A claim is represented as key/value pair combination. There are three types of claims Registered, Public and Private. The key part of the claim is limited to 3 characters
Registered: Predefined claims and can be viewed here

Public: Custom defined claims but need to be registered in public registry at

Private: Agreed custom claims between to applications.

Signature: Verifies that the message is not tampered during transmission.

Multiserver topology for Dynamics/SharePoint Setup

Tags

,

In this article we looked at how quickly trial labs can be setup with the use of AutomatedLab PS modules. In this tutorial we will use the Automated Lab PS modules to set up the CRM Farm topology

CRMFarmTopology

The Git repository here has a PS script DynamicsCEFarm.ps1  and a output file ScriptOutputCRMFarm.txt that details the results of script run note that AutomatedLab PS module by default will assign a password and this can the changed. Total elapsed time for initial server configuration was about 30 mintues.

AutomatedLab PS modules can also be used to install SQL Server and other products but for purposes of setting up test lab after initial server configuration I followed through the articles as per below to install and configure other services on Windows 2016 OS