Thursday, October 27, 2022

 Multitenant fullstack application implementation using open source. 

This part of the book explores open source implementation of multi-tenant applications specifically, with Spring Boot, JPA, Hibernate, and Flyway.  Many open source implementations such as Atlassian, Jira, Confluence, Trello, or BitBucket are quite popular.  

With a Java based stack for frontend and backend, the following changes would be required. 

  1. JPA will need the appropriate repository class.  

  1. @Repository 

Interface ResourceRepository extends JPARepository<Resource, Long> 

{ 

} 

  1.  A corresponding service class change for transactionality 

  1. @Service 

@Transactional 

class AResourceService { 

private ResourceRepository resourceRepository; 

} 

  1. Since the above will be partitioned based on tenants, one service could connect to different databases or schemas with: 

  1. A request interceptor that sets the appropriate tenant in the context using Spring: 

public abstract class TenantContext { 

public static ThreadLocal<String> currentTenant = new ThreadLocal<String>(); 

public static void setCurrentTenant(String tenant) { 

currentTenant.set(tenant); 

} 

public static string getCurrentTenant() { 

return currentTenant.get(); 

} 

public static void clear() { 

return currentTenant.remove(); 

} 

} 

And with the corresponding: 

@Component 

public class TenantRequestInterceptor implements 

AsyncHandlerInterceptor { 

private SecurityDomain securityDomain; 

public TenantRequestInterceptor(SecurityDomain securityDomain) { 

this.securityDomain = securityDomain; 

} 

@Override 

Public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { 

Return Optional.OfNullable(request) 

.map(req -> securityDomain.getTenantIdFromJwt(req)) 

.map(tenant->SetTenantContext(tenant)) 

.orElse(false); 

} 

 

@Override 

Public void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler, ModelAndView modelAndView) { 

TenantContext.clear(); 

} 

 

private boolean setTenantContext(String tenant)  

{ 

TenantContext.setCurrentTenant(tenant); 

return true;  

} 

} 

 

Finally, we just need to register this: 

@Configuration 

public class WebConfiguration implements WebMvcConfigurer { 

  

      @Autowired 

 private TenantRequestInterceptor tenantInterceptor; 

         

      @Override 

 public void addInterceptors(InterceptorRegistry registry) { 

     registry.addInterceptor(tenantInterceptor).addPathPatterns("/**"); 

 } 

         

} 

Wednesday, October 26, 2022

 Open-source multitenant solution 

This part of the book focuses on open-source for multitenant solution providers. Multitenancy goes deep to all levels of the infrastructure: front-end, middle-tier and backend. It might be easier to implement it in open source if we visualize it in two layers – the data plane layer and the application plane. 

The Data plane layer is all about data at rest and transit. Often, this involves partitioning on the data layer with separate partitions, tables, columns, identifiers and labels on the data storage schema and topics such as in Kafka, tags, domains and other data. 

The control plane layer is about context and access over the data and resources and primarily deals with organization, namespace and metadata. It secures and maps the users to the tenants via the Authorization component that can include an external Identity provider or an IAM solution. Many open-source infrastructures provide abilities to delegate IAM access to others. 

An authorization layer alone can convert a single tenant application into a multi-tenant solution where only the accesses are separated over the infrastructure as a whole taken as a resource. This works like an upgrade to the original infrastructure. The right policy model can simplify this transition even better. Policies can include role-based access control with tenant management, relationship based access control over a hierarchy where tenants become root-level relationship or attributes based access control with tenancy as an attribute. While role-based access control is the default policy model sought widely, relationship-based access control can help describe complex relationships between resources in a system. This approach facilitates a “policy-as-a-data” realm as opposed to “policy-as-a-code” realm. The policy is split between declarative rules and logic and can be visualized using a relationship graph and a hierarchical structure for assets such as folders and documents. Hierarchy can help with inheritance.

Attribute based access control emphasizes the use of attributes associated with the subject, the resource or the environment to determine whether access is granted or not. This results in a fine grained authorization model and when these attributes have dynamic values, there is a lot of flexibility achieved. Databases implement row-level security so this has some precedence. Authorization models can also be combined. 

Multi-tenant authorization does not need to be implemented from scratch. Often there is an existing library, product or solution that can be integrated into the Software-as-a-service. If it must be implemented, there are multiple options. Open Policy Agent (OPA) can be leveraged as an authorization microservice. Open Policy Administration Layer (OPAL) enables one to manage the authorization layer at scale, using PubSub topics and json data. Solutions like Permit.IO provide a way to integrate seamlessly for tenants. 

 

Tuesday, October 25, 2022

 

Convention_vs_Guidance – an example.

A multitenant solution provider for service deployment orchestration has a syntax for describing the stages of buildout. The sample for this looks something like this:

---

name: SERVICE1

service_identifier: abcdefgh-ijkl-mnop-qrst-uvwxyz012345

owner: Service1_Team

buildout_stages:

  newcloud.provisioning:

    - service1_newcloud_rt

  newcloud.prebootstrap:

    - service1_resources

  newcloud.bootstrap:

    - service1_pfdeploy

  newcloud.postbootstrap:

  newcloud.predeploy:

    - service1_newregion_rt

  newcloud.deploy:

    - service1_newregion

  newcloud.postdeploy:

    - service1_telemetry

    - send_service1_newcloud_signal

resources:

  service1_newcloud_rt:

    description:

  service1_pfdeploy:

    description:

  service1_resources:

    description:

  service1_newregion_rt:

    description:

  service1_newregion:

    description:

  service1_telemetry:

     description:

  send_service1_newcloud_signal:

     description:

 

The question is whether the stages can be mandated from the tenants for the deployment of their services, or should this just be a sample?

The answer is not that simple. If it were an enforcement, it might interfere with the organization that the services might want to keep. It is also inefficient if most of the stages are required but cannot be filled. The only drawback is if there is no convention, there is no consistency between service deployment artifacts. The other approach is to publish it as a guidance which is less restrictive and more prescriptive. The drawback for this approach is that all the benefits of publishing go away. The answer lies somewhere in between or dependent on the case.

Monday, October 24, 2022

 This article draws parallels to Microsoft 365 for enterprise tenants which include tenant models, optimal networking, identity, migration and device and app management. 

When we refer to a tenant, we refer to it by the tenant ID, but it is also possible to refer to them by the host names for the tenants in the deployment. A tenant specific sub-domain is set up in this case. The tenant host name, mytenant.myservice.com must be specified as an alternative in the tenant configuration.  The URL can specify the tenant ID and the tenant host name if we specify the host names as alternative IDs for tenants.  

Optimal networking involves optimizing the path between the on-premises users, and the closest location to the Microsoft Global Network, optimizing the access for remote users over VPN, using network insights to design the network perimeter for the office locations, optimizing access to specific assets hosted on SharePoint sites with the office 365 CDN, configure proxy and network edge devices to bypass processing for Microsoft 365 trusted traffic using an allowed list of endpoints. 

Optimal networking is only the first step in tenant management.  Identity Management is the next step. 

Identity infrastructure must be configured correctly, which is vital to managing the Microsoft 365 user access and permissions for an organization.  

There are two types of identity models which are Cloud only model and Hybrid model. User accounts only exist in the Azure AD tenant for the Microsoft 365 tenant in a cloud-only model.  Hybrid accounts have user accounts both in the on-premises Active Directory domain services as well as in the Azure AD tenant. 

The hybrid identity model and directory synchronization are the most common choice for enterprise customers who are adopting Microsoft 365. There are two types of authentications when using the hybrid identity model – the managed authentication and the federated authentication. 

In the managed authentication case, Azure AD handles the authentication process by using a locally stored hashed version of the password or sends the credentials to the on-premises Active Directory Domain Services.  In the federated authentication case, Azure AD redirects the client computer requesting authentication to another identity provider. 

 

Strong sign-in is another requirement for multitenant applications. This is enforced by capabilities such as Windows Hello for Business which replaces passwords with strong two-factor authentication, Azure AD Password protection which detects and blocks known weak passwords and their variants, MFA which requires user sign-ins to be subject to another verification beyond the user account password, identity and device access configurations such as the settings and policies that include conditional access, Intune, and Azure AD identity protection policies which protect against credential compromise. 

Determining which identity model to use and how to enforce strong user and device access is critical to the identity management for tenants. Besides that, only ongoing maintenance might be required for adding or modifying user accounts and groups, and adding or modifying identity and device access configuration to enforce sign-in security requirements. 

Enterprises can manage devices and the apps used on those devices with the help of Microsoft 365 Mobile Device Management and Mobile Application Management. There are two options for device management which include Microsoft Intune, which is a comprehensive device and app management solution for enterprises and Basic mobility and security which is a subset of Intune services. Intune helps with both MDM or MAM. MDM is used when users enroll their device into Intune. After a device is enrolled, it is a managed device and can receive organization’s policies, rules and settings. MAM helps to protect the organizational applications and their data by isolating it from the personal profile for the user on their devices and requiring strong sign-ins. A set of configurations is still required above MDM and MAM to ensure a secure and productive workforce and this includes Azure AD Conditional access policies, Microsoft Intune device compliance and app protection policies, and Azure AD Identity Protection user risk policies and additional policies of cloud applications. As with identity management, device and app management also involves maintenance to manage device enrollment, and revisions to settings and policies for additional applications, devices and security requirements.