Domain name considerations in Multitenant applications:   

This is a continuation of series of articles on hosting solutions and services on Azure public cloud with the most recent discussion on Multitenancy here This article discusses the domain name considerations in Multitenant applications.   

Just like identity pertains to a tenant, a domain name can also be used to identify a tenant. Requests are routed to the appropriate tenant based on the based on the subdomains and the custom domain names. 

A subdomain falls within a domain that is commonly shared across tenants. If the multitenant application is hosted by Contoso, all of Contoso’s tenants will be assigned subdomain names. The shared domnain name need not just be contoso.com and can have regional qualification such as us.contoso.com Many Azure Services use this approach. When subdomains are created under the domain name, there cannot be name collisions with the names of other tenants. The full domain name must be unique.

Wildcard DNS entries can be used to simplify the management of subdomains. Instead of creating DNS entries for individual tenants, a wildcard entry for *.contoso.com is sufficient to route all requests to a single IP address as with the use of an A record or to a canonical name as with the use of  CName record.

Subdomains with multi part stem domains allows many multitenant solutions are to be spread across multiple physical deployments. Multipart subdomain names help organize the tenants even across disparate geographical regions. When Contoso publishes a multitenant application for its customers, the tenant subdomains can map to the same CName so that adventureworks.contoso.com and fabrikam.contoso.com can be reached with the same CName record of us.contoso.com

Customers do not always need to publish a full name with the Contoso part from the company that hosts the multitenant applications. These can use custom domain names.

Azure DNS allows hosting a DNS zone and managing the DNS records for a domain in Azure. The domain must be delegated to the Azure DNS from the parent domain so that the DNS queries for that domain can reach Azure DNS. Since Azure DNS isn't the domain registrar, delegation must be configured properly.  A domain registrar is a company who can provide internet domain names. An internet domain is purchased for legal ownership. This domain registrar must delegate to the Azure DNS.  

The domain name system is a hierarchy of domains which starts from the root domain that starts with a ‘.’ followed by the top-level domains including ‘com’, ‘net’, ‘org’, etc. The second level domains are ‘org.uk’, ‘co.jp’ and so on. The domains in the DNS hierarchy are hosted using separate DNS zones. A DNS zone is used to host the DNS records for a particular domain. 

There are two types of DNS Servers: 1) An authoritative DNS Server that hosts DNS zones and it answers the DNS queries for records in those zones only and 2) a recursive DNS server that doesn’t host DNS zones but queries the authoritative servers for answer. Azure DNS is an authoritative DNS service. 

DNS clients in PCs or mobile devices call a recursive DNS server for the DNS queries their application needs. When a recursive DNS server receives a query for a DNS record, it finds the nameserver for the named domain by starting at the root nameserver and then walks down the hierarchy by following CNAMEs. The DNS maintains a special type of name record called an NS record which lets the parent zone point to the nameservers for a child zone. Setting up the NS records for the child zone in a parent zone is called delegating the domain. Each delegation has two copies of the NS records: one in the parent zone pointing to the child, and another in the child zone itself. These records are called authoritative NS records and they sit at the apex of the child zone

 This is a continuation of series of articles on hosting solutions and services on Azure public cloud with the most recent discussion on Multitenancy here This article discusses the Tenant signup and onboarding aspect in Multitenant applications.   

Tenants and their users are recognized by their identity in a multi-tenant application. Every user belongs to a tenant. A user signs in with her organizational credentials. She may have access to the data from her organization but nowt to the data from other tenants. She can register with the multitenant application/service and then after her account is created, she can assign roles to other members.    

The signup process is critical to multitenant applications which allows a customer to sign up their organization for the application. It allows an AD administrator to consent for the customer’s entire organization, to use the application. It collects credit card payment or other customer information. It performs any one-time per-tenant setup needed by the application.  
When the application authenticates with the user, the application needs permission to read the user’s profile. The first time the user signs in, a consent page is shown that lists all the permissions that the application needs to perform the authentication. By clicking Accept, the user grants permission to the application.  A consent is granted on a per-user basis but azure AD supports admin consent for the entire organization. The consent page will be suitably worded for the entire organization.  
Several requirements are available for the tenant sign up process. A tenant must sign up before users can sign in, Sign up uses the admin’s consent flow. It adds the user’s tenant to the application database. After the tenant signs-up, it shows an onboarding page. Usually, a multitenant application has an AccountController class where the sign-in action returns a ChallengeResult. This enables the OpenID connect middleware to redirect to the authentication endpoint. The default way is to trigger authentication in ASP.Net core. The Signup action that is different from the signin action also returns a ChallengeResult but it adds state information to the AuthenticationProperties in the ChallengeResult This is relayed to the OpenID Connect state parameter which round trips during the authentication flow from the Azure AD. When the user authenticates with the AzureAD, it gets redirected back to the application. The authentication ticket contains the state. The admin consent flow is triggered by adding a prompt to the query string in the authentication request. This prompt is only needed during sign-up and the regular sign-in should not include it.  

The code sample appear like this: 

[AllowAnonymous] 

public IActionResult SignIn() 

{ 

    return new ChallengeResult( 

        OpenIdConnectDefaults.AuthenticationScheme, 

        new AuthenticationProperties 

        { 

            IsPersistent = true, 

            RedirectUri = Url.Action("SignInCallback", "Account") 

        }); 

} 
[AllowAnonymous] 

public IActionResult SignUp() 

{ 

    var state = new Dictionary<string, string> { { "signup", "true" }}; 

    return new ChallengeResult( 

        OpenIdConnectDefaults.AuthenticationScheme, 

        new AuthenticationProperties(state) 

        { 

            RedirectUri = Url.Action(nameof(SignUpCallback), "Account") 

        }); 

} 

Since many users can map to the same tenant, the application database could include a tenants table with id and issuerValue attributes and a user table with Id, tenantId, ObjectId, DisplayName, and Email properties for taking the following actions. If the tenant’s issuer value is not in the database, the tenant has not signed up. If the user is signing up, the tenant is added to the database and the authenticated user is added to the corresponding table. Otherwise, the normal signin process is completed. 

Application roles are used to assign permissions to the users. It defines the following roles: Administrator, Creator and Reader. These roles imply permissions during the authorizations. There are three main options to assign roles: Azure AD App Roles, Azure AD security groups, Application Role Manager 

 When the application authenticates with the user, the application needs permission to read the user’s profile. The first time the user signs in, a consent page is shown that lists all the permissions that the application needs to perform the authentication. By clicking Accept, the user grants permission to the application.  A consent is granted on a per-user basis but azure AD supports admin consent for the entire organization. The consent page will be suitably worded for the entire organization.

Several requirements are available for the tenant sign up process. A tenant must sign up before users can sign in, Sign up uses the admin’s consent flow. It adds the user’s tenant to the application database. After the tenant signs-up, it shows an onboarding page. Usually, a multitenant application has an AccountController class where the sign-in action returns a ChallengeResult. This enables the OpenID connect middleware to redirect to the authentication endpoint. The default way is to trigger authentication in ASP.Net core. The Signup action that is different from the signin action also returns a ChallengeResult but it adds state information to the AuthenticationProperties in the ChallengeResult This is relayed to the OpenID Connect state parameter which round trips during the authentication flow from the Azure AD. When the user authenticates with the AzureAD, it gets redirected back to the application. The authentication ticket contains the state. The admin consent flow is triggered by adding a prompt to the query string in the authentication request. This prompt is only needed during sign-up and the regular sign-in should not include it.

 This is a continuation of series of articles on hosting solutions and services on Azure public cloud with the most recent discussion on Multitenancy here This article discusses the Tenant signup and onboarding aspect in Multitenant applications.  

Tenants and their users are recognized by their identity in a multi-tenant application. Every user belongs to a tenant. A user signs in with her organizational credentials. She may have access to the data from her organization but nowt to the data from other tenants. She can register with the multitenant application/service and then after her account is created, she can assign roles to other members.   

The signup process is critical to multitenant applications which allows a customer to sign up their organization for the application. It allows an AD administrator to consent for the customer’s entire organization, to use the application. It collects credit card payment or other customer information. It performs any one-time per-tenant setup needed by the application. 

When the application authenticates with the user, the application needs permission to read the user’s profile. The first time the user signs in, a consent page is shown that lists all the permissions that the application needs to perform the authentication. By clicking Accept, the user grants permission to the application.  A consent is granted on a per-user basis but azure AD supports admin consent for the entire organization. The consent page will be suitably worded for the entire organization. 

Several requirements are available for the tenant sign up process. A tenant must sign up before users can sign in, Sign up uses the admin’s consent flow. It adds the user’s tenant to the application database. After the tenant signs-up, it shows an onboarding page. Usually, a multitenant application has an AccountController class where the sign-in action returns a ChallengeResult. This enables the OpenID connect middleware to redirect to the authentication endpoint. The default way is to trigger authentication in ASP.Net core. The Signup action that is different from the signin action also returns a ChallengeResult but it adds state information to the AuthenticationProperties in the ChallengeResult This is relayed to the OpenID Connect state parameter which round trips during the authentication flow from the Azure AD. When the user authenticates with the AzureAD, it gets redirected back to the application. The authentication ticket contains the state. The admin consent flow is triggered by adding a prompt to the query string in the authentication request. This prompt is only needed during sign-up and the regular sign-in should not include it. 

 Identity Management in Multitenant applications:  

This is a continuation of series of articles on hosting solutions and services on Azure public cloud with the most recent closure on Service Fabric discussion as per the summary here. This article discusses the claims-based identities in the new series on Multitenant applications. 

Tenants and their users are recognized by their identity in a multi-tenant application. Every user belongs to a tenant. A user signs in with her organizational credentials. She may have access to the data from her organization but not to the data from other tenants. She can register with the multitenant application/service and then after her account is created, she can assign roles to other members.  

Identity and access management provide built-in features to support all these scenarios. So, they simplify the logic that the multi-tenant application must execute to log them in. Let us say there are two users alice@contoso.com and bob@fabrikam.com who want to login to a multitenant SaaS application. Since they belong to different tenants, the application must map the user to the right tenant. Alice cannot have access to Fabrikam data in this case.  

Azure AD can handle sign-in and authentication of different users and the multitenant application is the same physical instance that recognizes and isolates the tenants to whom the users belong. 

During authentication, such as when a user accesses a resource, the application must determine the user’s tenant. If the tenant is already onboarded to the application, then such a user does not need to create a profile. Users within an organization are part of the same tenant.  Any indicators for the tenancy that comes from the user such as the domain name of the email address used to login cannot be trusted. The identity store must be used to resolve the tenant.   

During the authorization, the tenant determination for the identity involved must be repeated.  Users must be assigned roles to access a resource. The role-based access control relies on the role assignments from the tenant administrator or the user if the resource is owned by the user. The role assignments are not made by the tenant provider.  

Claims-based identities in Azure AD involves sending an ID access token that contains a set of claims about the user. A claim is simply a piece of information, expressed as a key-value pair. For example, the email associated with the user is a claim. Azure AD authenticates the user and creates the claim. The claims are trusted because the issuer is trusted. The issuer is also referred to as the Identity Provider (IDP) 

Using this technique, an application is no longer responsible for the following: 1) authenticating users 2) storing user accounts and passwords, 3) calling membership providers like enterprise directories to lookup user information 4) integrating with identity systems from other organizations and 5) providing implementations for several protocols to be compliant with industry standards and business practice. All the identity related decisions are based on claims supplied by the user.  An identity is a set of attributes that describe a principal. A claim is a piece of identity information. The more slices of information an application receives, the more complete the pie representing the individual.  Instead of the application looking up the identity, it merely serializes them to the external system. A security token is a serialized set of claims that is digitally signed by the issuing authority. It gives the assurance that the user did not make up the claim. An application might receive the claim via the security header of the SOAP envelope of the service. A browser-based web application arrives through an HTTP POST from the user’s browser which may later be cached in a cookie if a session is enabled. The manner might vary depending on the clients and the medium but the claim can be generalized with a token.  Open standards including some well-known frameworks are great at creating and reading security tokens. A security token service is the plumbing that builds, signs and issues security tokens. It might implement several protocols for creating and reading security tokens but that is hidden from the application.   

 Identity Management in Multitenant applications: 

This is a continuation of series of articles on hosting solutions and services on Azure public cloud with the most recent discussion on Service Fabric as per the summary here. This article discusses the architectural approaches for securing a multitenant application. 

Tenants and their users are recognized by their identity in a multi-tenant application. Every user belongs to a tenant. A user signs in with her organizational credentials. She may have access to the data from her organization but not to the data from other tenants. She can register with the multitenant application/service and then after her account is created, she can assign roles to other members. 

Identity and access management provide built-in features to support all these scenarios. So, they simplify the logic that the multi-tenant application must execute to log them in. Let us say there are two users alice@contoso.com and bob@fabrikam.com who want to login to a multitenant SaaS application. Since they belong to different tenants, the application must map the user to the right tenant. Alice cannot have access to Fabrikam data in this case. 

Azure AD can handle sign-in and authentication of different users and the multitenant application is the same physical instance that recognizes and isolates the tenants to whom the users belong.

During authentication, such as when a user accesses a resource, the application must determine the user’s tenant. If the tenant is already onboarded to the application, then such a user does not need to create a profile. Users within an organization are part of the same tenant.  Any indicators for the tenancy that comes from the user such as the domain name of the email address used to login cannot be trusted. The identity store must be used to resolve the tenant.  

During the authorization, the tenant determination for the identity involved must be repeated.  Users must be assigned roles to access a resource. The role-based access control relies on the role assignments from the tenant administrator or the user if the resource is owned by the user. The role assignments are not made by the tenant provider. 

On-premises AD can be federated with the Azure AD with the help of a connector. Security can be further improved by enabling private connectivity to the multitenant application. Security can also be improved for connectivity between the application and other Azure PaaS services over Azure Private Link. These connections might include other web applications, Azure SQL databases, Azure Storage, Azure KeyVault, and all the services that support Azure private endpoints for inbound connectivity. Azure Private Link sets up a private endpoint for the PaaS services, web applications, Azure SQL Database, Azure Storage Account, and the Azure KeyVault. The On-premises network and the Azure virtual network can be connected via a Site-to-Site (S2S) VPN or Azure ExpressRoute private peering. The on-premises network and the remote Azure virtual network are connected via private peering.  An on-premises network that already has a domain name system solution in place and use a conditional forwarder to forward DNS traffic to Azure DNS. This forwarder resolves all the DNS queries via a server-level forwarder to the Azure provided DNS service. Azure Firewall and Virtual network configurations are still required.  The application rules for allowing communication between the VNet Integratiion subnets and the private endpoints of Paas Resources are written with the help of the Azure Firewall.

An alternative approach for private connectivity is to use App Service Environment to host the multitenant application in an isolated environment. For some other Azure Services, there is no alternative to using private endpoints for highly secure and private connections from WebApplications.

Application routing can be configured to route either all the traffic or only private traffic into the virtual network. The former is used to block all traffic to public ip addresses. A network security group can also be used to block outbound traffic to resources in the virtual network.

 Data in transit and multitenancy:

This is a continuation of series of articles on hosting solutions and services on Azure public cloud with the most recent discussion on Service Fabric as per the summary here. This article discusses the architectural considerations for a multitenant application.

Data in transit usually goes through some set of operations that are usually referred to as Extract-Transform-Load or ETL in short. In the earlier days, online transactional data would be stored in relational databases and the data would eventually make its way to the data warehouses. Data transfers between databases and warehouses used ETL commonly.  A designer tool was made available that made it easy to setup the data flows and the operators.  

A data warehouse consolidated the data. All the analysis stacks were built over this data at rest.  Nowadays, a pipeline is built to facilitate capturing data, providing streaming access and providing infinite storage. Companies are showing increased usage of event based processing and pipelined execution. This form of execution involved acquisition, extraction, integration, analysis, and interpretation    

As unstructured data storage became popular and the map-reduce methods gained usage over this data, many other forms of storage came into the picture which made data transfers even more necessary and widespread. 

Access to the data had to be standardized. Fortunately, with the widespread usage of Object Storage, data access became easy and ubiquitous with S3 API.  Object storage was more than web accessible limitless cloud storage. It also served as a storage where data transfers can be registered, chronicled, studied and improved –all on premise over an organizations network with no limit to the number of sites or instances supported. Object storage transformed from being a passive storage product to a storage layer that actively builds metadata, maintains organizations, rebuilds indexes from data and metadata and performs vectorized execution centric optimizations. This we can refer to as data harvesting. 

When harvesting was deeper, it is like network packet capture. The salient notion is that data capture is like harvesting. Both make use of proxies as a man in the middle which provide little or no disruption to ongoing operations while facilitating the storage and analysis of data for future. Data capture goes a step deeper into the hierarchy of application stack by tapping into the network. Most data in transit are already in the form of network packets. Data is fragmented and sent to the destinations over protocols. They are also encrypted. However, the end points of the network tunnel are safe with the sender and receiver. A networking layer that facilitates publishing of data to interested and authorized subscribers prior to send and receive enables the decoupling of a packet sniffer to be specific to the sender or receiver.  In such a case, we alleviate the data harvesting from data centric operations to the network layer where the TCP send and receive queue support publishing and subscribing with added annotations. 

With the improved data transfers and ease of use data can remain in transit albeit within a more encompassing storage layer. Storage and networking can both implement publisher subscriber mechanisms.