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 resilient identity and access management with Azure AD.

Any component of Identity and Access Management is the process, policy and technology framework that covers management of identities and what they can access. IAM includes components that support authentication and authorization of user and other accounts in the system.

Any component of an IAM system can cause disruption. IAM resilience is the ability to endure disruption and recover with minimal impact to business. It is promoted by planning for disruptions assuming they will occur, reducing dependencies, complexity and single points of failure and ensure comprehensive error handling.

Recognizing and planning for contingencies is important but adding more identity systems with their dependencies and complexity could reduce their resilience. Azure AD managed identities provide such resilience. Instead of relying on certificate-based authentication alone, improving the resilience of the application by using Azure AD managed identities is recommended.

There are other elements to manage resilience, and these include applications that rely on the IAM system, public infrastructures that your authentication calls and include telecom companies, internet service providers and public key providers, cloud and on-premises identity providers, other services that rely on the IAM and the APIs to connect the services and on-premises components in your system.

Dependencies can be managed and authentication calls can be reduced so that the application is less chatty. Reducing the number of authentication calls and the number of dependencies in those calls increases resilience.

Long lived revocable tokens can be issued and used to overcome the short token validity period an application or another resource is accessed with. When the validity period is long, the token can be presented multiple times to gain access. Acquiring a new token reduces resilience due to interruption or involvement of user. But this might require weighing against the policy evaluations

Hybrid and on-premises resilience can be improved with by introducing an application proxy.

A multitenant application does not control how many tenants or the direct ownership of a resource to its tenant. The customer has the complete say in this. They may want to reassign a resource to another tenant. For example, if they decide to join a machine to a different tenant, they need to disconnect from the first tenant and then register again with the new tenant.  The single sign-on (SSO) option for password hash synchronization and pass-through authentication can be used with only one Azure AD tenant.

 

 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 securing the backend WebAPI for multitenant solutions.

A backend WebAPI can manage CRUD operations on resources. The frontend web application sends an HTTP request to the Web API and it returns a JSON response to the caller. There are no anonymous requests  so the web application must authenticate using say OAuth2.0 Bearer Tokens. Since we are considering a server to server scenario, the calling application does not make any AJAX calls to the API from the browser client. There are two main approaches to handle this for a multitenant application.

First, a delegated identity for the user could be  used where the web application authenticates with the user’s identity. 

Second, the application authenticates with its credentials such as its client ID for an OAuth token requested via client credential flow.

The differences between the first and the second  are quite a few. With Delegated user identity, the bearer token sent to the Web API contains the user identity. The Web API makes authorization decisions based on this identity. The web application needs to handle errors from the Web API when the user is not authorized to perform an action. The authorization decisions from the web application will impact the visibility of certain user interface elements. The WebAPI can potentially be used by untrusted clients.

With the ApplicationIdentity, the web API does not get information about the user. The web API cannot perform any authorization based on the user identity but it cannot be used by an untrusted client. The approach may be somewhat simpler and more maintainable because there is no authorization logic.

The credential in both these cases involves an access token. Azure AD can issue token based on memberships to the Active Directory.

The Web API must be registered with the Azure AD. The client ID of the web application is added to the web API application manifest. The web application must be given permission to call the web API.

The Web API must authenticate the bearer token say with the middleware that enables the application to receive the open ID Connect bearer tokens. The token can be validated in the JwtBearerEvents.TokenValidated event. The issuer is sent it the “iss” claim. Authorization can be role based and resource based. The middleware handles the authorization responses as long as the authentication scheme. This returns a 401 status code when the user is not authenticated. The web API must just specify the policy in the Authorize attribute.

A multitenant application does not control how many tenants or the direct ownership of a resource to its tenant. The customer has the complete say in this. They may want to reassign a resource to another tenant. For example, if they decide to join a machine to a different tenant, they need to disconnect from the first tenant and then register again with the new tenant.  The single sign-on (SSO) option for password hash synchronization and pass-through authentication can be used with only one Azure AD tenant. 

 

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 identity and group management considerations for multitenant solutions.

A multitenant application does not control how many tenants or the direct ownership of a resource to its tenant. The customer has the complete say in this. They may want to reassign a resource to another tenant. For example, if they decide to join a machine to a different tenant, they need to disconnect from the first tenant and then register again with the new tenant.  The single sign-on (SSO) option for password hash synchronization and pass-through authentication can be used with only one Azure AD tenant.

When resource and users proliferate, groups come in handy to organize them and manage actions against many users. The Azure AD can use groups to assign access to a SaaS application that’s integrated with AD. A security group can be used to secure access to a resource. Members can be added or removed from the security group without changing the security model of the resource access control. This capability can be added to hundreds of resources across the application.

The role assignment for a group can be done directly with the Azure AD admin center and this can be added from the application gallery. Users and groups can be selected and then users can be added to a role. The users or groups can be assigned to the multitenant application or a resource within the application. Both app and resource access can be managed this way.

Azure AD gives access to the organization’s resources by providing access rights to a single user or an entire Azure AD group. Nested groups and users can inherit permissions which saves the effort of adding permissions one by one. There are four ways of assigning access rights and permissions. Rights can be directly accessed assigned to the user. They can be assigned to a group instead. There can be assignment based on rules where the rule defines how users are assigned to resources. Access can be granted from an external source such as an on-premise directory or the multitenant application.

 A resource owner creates a group and assigns the group to the resource. The group owner assigns users to the group who become members of the group and gain access to the resource. The group owner can let the users find their groups to join, instead of assigning them. The owner can also setup the group to automatically accept all users that join to or require approval. When a user requests to join a group, the request is forwarded to a group owner. If it is required, the owner can approve the request and the user can be notified but if there are multiple owners and one of them disapproves, the user is notified but isn’t added to the group. Automatic approval eliminates the onus on the group owner.sw

Azure resources are deployed and managed through a hierarchy. Most resources are deployed into resource groups which are contained in subscriptions. This hierarchy pertains to a tenant. When we deploy the resources, we have the option to isolate them at different levels. Different models can be used in different components of the same solution.  Groups can be used to secure the appropriate level.

Reference: Multitenancy: https://1drv.ms/w/s!Ashlm-Nw-wnWhLMfc6pdJbQZ6XiPWA?e=fBoKcN        

 

 

 

Multi-tenancy

 

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 resource migration considerations in using CosmosDB for multitenant solutions.

A multitenant application solution can involve multiple resources across multiple tenants and the application might be responsible to support: 1) Partitioning, 2) Managing request units from tenant workloads, 3) Customer-managed keys and customizations per tenant, 4) isolation models and 5) hybrid approaches. The multitenant application does not control how many tenants or the direct ownership of a resource to its tenant and the customer has the complete say in this. They may want to reassign a resource to another tenant. For example, if they decide to join a machine to a different tenant, they need to disconnect from the first tenant and then register again with the new tenant.  The single sign-on (SSO) option for password hash synchronization and pass-through authentication can be used with only one Azure AD tenant.

Resource organization helps a multi-tenant solution with tenant-isolation and scale. There are specific tradeoffs to consider with multi-tenant isolation and scale-out across multiple resources. Azure’s resource limits and quotas and scaling the solution beyond these limits will be discussed.  

When there is an automated deployment process and there is a need to scale across resources, the way to deploy and assign tenants must be decided. As we are approaching the number of tenants that can be assigned to a specific resource, we must detect the threshold. When we plan to deploy new resources, it must be decided whether they will be ready just in time or ready ahead of time.  

When assumptions are made in code and configuration, they can limit the ability to scale. There might be a need to scale out to multiple storage accounts, but the application tier might be assuming a single storage account for all tenants.  

 

Azure resources are deployed and managed through a hierarchy. Most resources are deployed into resource groups which are contained in subscriptions. This hierarchy pertains to a tenant. When we deploy the resources, we have the option to isolate them at different levels. Different models can be used in different components of the same solution.  

Resources that are shared across multiple instances can still achieve isolation in a single instance for all the workloads from the tenants. When we run a single instance of resource, the service limits, subscription limits and the quota apply. When these limits are encountered, the shared resources must be scaled out.  

 

Isolations within a shared resource requires the application code to be fully aware of multitenancy, and to restrict the data for a specific tenant. An alternative to this is to separate resources in resource groups. These help to manage the lifecycles of resources. Those resources that are in a resource group can be deleted all at once by deleting the resource group. A naming convention, strategy and resource tags or a tenant catalog database is required in this case. Resource groups can also be separated into subscriptions. This enables us to easily configure policies and access control by putting resource groups into a shared subscription. There is a limit to the maximum number of resource groups that can be put in a subscription so they must spill over to a new subscription upon exceeding. Separate subscriptions help achieve complete isolation of tenant specific resources and they can be programmatically created. Azure reservations can also be used across subscriptions. The only difficulty is to request quota increases when there are many subscriptions. The Quota API is helpful to some resource types and quota increases must be requested by initiating a support case. Tenant specific subscriptions can be put into a management group hierarchy so that it enables easy management of access control rules and policies.  

 

Multitenancy

 

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 architectural considerations in using CosmosDB for multitenant solutions.

A multitenant application solution can involve a CosmosDB storage for the following reasons: for near-limitless storage, as a document store, for multi-region availability and separation of read-write and read-only accesses, for high throughput and universal web access. Features of Azure Cosmos DB that support multitenancy include: 1) Partitioning ,  2) Managing request units, 3) Customer-managed keys, 4) isolation models and 5) hybrid approaches.

We begin partitioning with CosmosDB containers. We create containers that are shared across multiple tenants. The tenant identifier can be used as a partition key or multiple partition keys can be used for a single tenant. A well-planned partitioning strategy implements sharding pattern. A shard typically contains items that fall within a specified range determined by one or more attributes of data. These attributes form the shard key and should be static since they are not based on the data that might change. This helps with physically organizing the data. All data accesses are directed towards the appropriate shard.  The sharding logic can be implemented as part of the data access code or it could be implemented by the data storage system. CosmosDB spreads the tenants across multiple physical nodes to achieve a high degree of scale.

CosmosDB’s pricing model is based on the number of request units per second that are provisioned or consumed. A request unit is a logical abstraction of the cost of database operation or query. Throughput is a defined number of request units per second that is provisioned for a workload. The determination of throughput affects the performance and price of CosmosDB resources.

When separate containers are provisioned for each tenant within a shared database, the request units can be provisioned for the entire database and all the tenants can share them.  But this approach may be susceptible to the noisy neighbor problem because a single tenant’s container might overuse the shared provisioned request units. Once the noisy tenants are identified, they can be put into a dedicated container and given their own request units. CosmosDB also provides a serverless tier which is suitable for workloads that have intermittent or unpredictable traffic. These approaches can be mixed and matched.

Some tenants might require their own encryption keys. Such tenants need to be deployed using dedicated CosmosDB accounts.

There are several forms of isolation models. These include: shared containers with partition keys per tenant, containers with shared throughput per tenant, containers with dedicated throughput per tenant and a database account per tenant. Each of these models have isolation options.

The shared containers with partition keys per tenant allows us to share throughput across tenants grouped by container which lowers cost on noisy tenants or enable easy queries across tenants by putting those tenants in a container since the queries are bounded by containers.

The container with shared throughput per tenant allows throughput across tenants to be shared because they are grouped by database or provide easy management of tenants since a container can be dropped when a tenant leaves.

The container with dedicated throughput per tenant has independent throughput options and eliminates noisy neighbors or allows the tenants to be grouped within database accounts based on regional needs.

The database account per tenant has independent geo-replication knobs since it is per tenant or it could provide multiple throughput options where the dedicated throughput eliminates noisy neighbors.

These constitute some of the approaches for designing multitenant solutions with CosmosDB storage.

Reference: Multitenancy: https://1drv.ms/w/s!Ashlm-Nw-wnWhLMfc6pdJbQZ6XiPWA?e=fBoKcN         

 

 Mails can be considered as unstructured data. Their usage by exchange clients is easily supported by unstructured storage. Unstructured storage has several benefits of traditional online relational stores. Moreover, it provides a new paradigm to support new use cases that go beyond browsing and searching. It relaxes the restrictions on mail store sizes.  The number of times a network is traversed also matters in the overall cost for data. The best cost for data is when data is at rest rather than in transit. The number of times a network is traversed also matters in the overall cost for data. The best cost for data is when data is at rest rather than in transit and object storage can serve as the sink for all mails and inbox clients need not store anything locally. Web clients can provide even more features with text mining. 

File-systems have long been the destination to store artifacts on disk and while file-system has evolved to stretch over clusters and not just remote servers, it remains inadequate as a blob storage. Data writers have to self-organize and interpret their files while frequently relying on the metadata stored separate from the files.  Files also tend to become binaries with proprietary interpretations. Files can only be bundled in an archive and there is no object-oriented design over data. If the storage were to support organizational units in terms of objects without requiring hierarchical declarations and supporting is-a or has-a relationships, it tends to become more usable than files. The modular storage described in this document enhance the use of object storage and do not compete with the usages of elastic file stores.    

As compute, network and storage are overlapping to expand the possibilities in each frontier at cloud scale, message passing has become a ubiquitous functionality. While libraries like protocol buffers and solutions like RabbitMQ are becoming popular, Flows and their queues can be given native support in unstructured storage. We discussed a  layer over object storage. Here we expand the definition and storage of Flows.  

Traditional relational databases have long cherished an acceptance for storing data that requires interpretations. However, the chores associated with converting data to structured form and amenable to querying can be relaxed with native support for rich non-hierarchical data organization from storage layer and transformation to a different class of unstructured storage.   

 While public cloud object storage solutions offer cloud-based services such as Amazon’s Simple Notification Services and Azure Notification hubs, on-premise object storage has the ability to make the leap from standalone storage offering to a veritable solution integration packaging. Public-Cloud offer robust myriad features for their general-purpose cloud services while the flows and quality of service are specialized usages of the object storage.  We use annotators to enhance the role of object storage in vectorized execution. Annotators add metadata in data transfers. When we inject annotations in the data flow we can manage them better without requiring any changes to source or destination.  

The ability to take the onerous routines of using object storage as a storage layer from the layer above across different data sources enables a thinner upper layer and more convenience to the end user. The customizations in the upper layer are reduced and the value additions bubble up the stack.    

An Object Storage offers better features and cost management, as it continues to stand out against most competitors in the unstructured storage. The processors lower the costs of usage so that the total cost of ownership is also lowered making the object storage whole lot more profitable to the end users.   

 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 architectural approaches for web applications in multitenant solutions. 

A multitenant application solution can involve a web application where different tenants customize their web user experience but otherwise share the same basic business requirements.  Examples of large multitenant applications are Microsoft 365, Outlook.com and VisualStudio.com  

The provider for the multi-tenant solution intends to optimize operational and cost efficiencies with a shared platform and a single version can meet the needs of many tenants and their customers, which allows consolidation of system administration tasks  such as monitoring, performance tuning, software maintenance and data backups. The most significant goals and requirements from a providers perspective includes provisioning, maintainability and monitoring. Provisioning new tenants for the application must be automated for cases where the number of tenants is large. Maintenance activities must not stop the business operations of any tenant who are using it.Monitoring must be performed at all times and enable troubleshooting. A properly implemented multitenant application will pass on the following benefits to its tenants: Isolation of tenants’ data and operations so that one does not impact another, availability with guarantees of a specific SLA, scalability to meet the various demands of the tenants without the degrading the experience of one another, lowered costs from shared resources at various levels rather than dedicated solutions, and customizability for the end-users. 

The tenants have some more expectations from the multitenant solution but they also fall into the categories of profitability, billing, multiple service levels, provisioning, maintainability, monitoring and automation 

Isolation can be achieved for web applications by segmenting website tenants by host headers, with or without TLS communications, segmenting based on query parameters or using web services and worker roles where worker roles typically process data on the backend and the web roles act as the frontend for the applications. 

Storage can be achieved using Azure SQL database or Azure Storage services. This provides access for large amounts of unstructured data and the blob service, which provides services to store large amounts of unstructured text or binary data such as video, audio and images. 

Data can be secured with per-tenant SQL logins, specifying a container level access policy, adjusting permissions without having to issue new connection string and protecting with shared access signatures. 

Queues can be used to drive processing on behalf of tenants and may be used to distribute work required for provisioning or management. Service Bus which is a messaging infrastructure allows applications to exchange messages in a loosely coupled way with high scalability and resiliency.  

Networking services support authentication and improve manageability of hosted applications. These services include Azure Virtual Network which helps provision and manage private networks, the Traffic Manager that allows load balancing for web application traffic and Azure AD which provides identity management and access control. 

Provisioning of resources can be automated in a variety of ways. These include worker roles that provision and de-provision per tenant resources, collect metrics for metering and manage scale in response to threshold exceeds for key performance indicators. The same role may also be used to push out updates and upgrades to the solution. Storage containers and blobs can be segregated based on naming conventions to provide isolation of tenant data and support provisioning. Database actions can be automated with Data Definition Language based scripts, deploying packages remotely, and syncing from master database. Data can also be imported and exported. 

These constitute some of the approaches for designing web application based multitenant solutions.