Building Multi Tenant Applications in Java v1.0

Building Multi Tenant Applications in Java v1.0

Building Multi Tenant Java Applications Rajesh Venkatesan Senior Architect, HCL Technologies [email protected] Multi Tenancy An Overview Ability to cater to multiple customers using a shared instance of Software/Hardware Time Share ASP End User Web Apps Inability of SOHO and SMB segments to adopt IT Non IT Businesses getting entrenched in managing IT Thats what this session is about 2 Multi Tenancy Impact in the real world

Single Vs MultiTenancy 3 Architectural Facets of Multi Tenancy in the Software World Virtualized Hardware Inbound Database Outbound Application Servers Shared Infrastructure Integration Configuration over Customization Security

Standardization of UI Data Model Data Security Business Logic Application Security 4 Shared Infrastructure Database Typically Multi Tenancy at the database level has 3 standard patterns Separate Database Traditional Isolated Database Instance Per Customer Shared Database Separate Schema Customers get their own schema but are co-hosted in the same database Shared Database Shared Schema Drives the highest efficiency. All Customers data is stored in the same database and schema with a tenant id qualifier Isolated Isolated

Shared Separate DB Separate Schema Shared Schema Source: Multi Tenant Data Architecture, Frederick Chong, Gianpaolo Carraro, and Roger Wolter Microsoft Corporation 5 Shared Database Multi Tenancy Patterns Pros and Cons Separate Database Shared Database Separate Schema Trade Off Considerations Compliance/Regulatory Cost Operations Time to Market Liability Shared Database Shared Schema

6 Database Multi Tenancy Implementation Isolated Database and Shared Database Separate Schema Standard Data Access simply returns the appropriate connection based on tenant context From From aa JDBC JDBC Perspective Perspective this this implies implies different different connection connection strings strings based based on on the the customer. customer. Typical Typical Tenant

Tenant Context Context is is set set by by an an intercepting intercepting filter filter and and obtained obtained at at the the DAO DAO layer layer possibly possibly via via aa ThreadLocal ThreadLocal variable variable For For Hibernate Hibernate implement implement aa Tenant Tenant aware aware ConnectionProvider

ConnectionProvider and and switch switch off off the the second second level level cache. cache. Shared Database Shared Schema Approach 1 Business Logic and Data Access is aware of multi tenant context and therefore query appropriately Pros Easy to build Cons High Probability of bugs leading to data leakage Approach 2 For For Hibernate Hibernate Use Use Filters Filters Abstract Multi Tenancy concern to the Data Access

Layer and write business logic without tenant context. Use Use Hibernate Hibernate Shards Shards Data Access Layer automatically adds tenant context to all data calls 7 Integration Typical integration concerns when applications move out of customer premises include ? ? How can I receive notification ? Is there standard integration ?

How can I push data to the application How do I orchestrate my business process Familiar? SOA? 8 Integration Contd Fundamentally the application must support well defined interfaces for inbound Integration as well as Outbound Integration Inbound Integration Implementation Expose services SOAP Technology Independent Axis, XFire Standards Based High Security Multi Tenant Aware

WSS4J Well Defined Standard WSS for Multi Tenant Security (Username/Token, X509 Tenant Certificate, SAML, Kerberos) REST Easy Integration Simplicity Security to be built on top. JAX-WS 9 Integration Contd Outbound Integration Allow Tenants to register for integration events. Push Vs Pull Push Synchronous Data can pushed to waiting WS endpoints Publish Standard Web Service Interfaces that customers can implement. Multi Tenant aware integration layer appropriately calls out the tenant specific interface. Problem with availability of customer endpoints Push Asynchronous Expose Secure Asynchronous Messaging Infrastructure. Heavy Vs Light Weight Events

For security reasons and other reasons, push non-critical information alone into the message. The listening party then calls back via standard web service inbound interface for the actual message. Push the entire message with all relevant information. The Infrastructure is absolutely secure. The messaging infrastructure takes responsibility of ensuring delivery. 10 Security Facets of Security Physical Security Security Data Security Application Security 11 Data Security JCA/JCE Use tenant specific encryption when required. Decouple encryption awareness from the data layer allowing data leaks to still be harmless Data at Rest

TradeOffs Database functions cannot be applied on encrypted fields Performance Tokenization of Data Only a token reference is stored in the database. Actual data has to come from a high security data protection server Data in Transit Use Secure means of transfer (https) and add authentication/ authorization layer on top. Use In Wire Encryption for highly critical data JSSE 12 Application Security Application Security is not different from traditional applications but some aspects become a lot more critical. Exposing the application on the web brings about a gamut of application security threats. Be Aware of possible security vulnerabilities and address them. The OWASP Top Ten Project ( is a good place to look. A1: Injection A2: Cross-Site Scripting (XSS) A3: Broken Authentication and Session Management

A4: Insecure Direct Object References A5: Cross-Site Request Forgery (CSRF) A6: Security Misconfiguration A7: Insecure Cryptographic Storage A8: Failure to Restrict URL Access A9: Insufficient Transport Layer Protection A10: Unvalidated Redirects and Forwards 13 Application Security Contd Some of the security best practices for applications Encrypt all communication between the browser and server via SSL. Strong password policy enforcement using configurable password policy. Passwords are stored after one way encryption in the database. It is impossible to know user passwords. Auto-Generated Passwords automatically expire after xx hours. Use of token based authentication with zero trust on server side Sessions. All access to the application is authenticated and is either secured by an authentication token or via certificates. Decoupled Authentication and Authorization and consolidation of concerns in order to establish a single point of control of user access. RBAC ensuring there are no super-users who get access to the system. Extensive Logging Capability ensuring every action is traceable to the user, request and session along with the actual change to the database. Database credentials created with named permissions. OS credentials created with named permissions All Inbound and Outbound interface points must be secured by default. (SSL) Additional Tenant Aware Security measures like

Tenant Specific Certificates 14 Application Security Federated Identity Tenant 1 n Sig In Corporate LDAP Multi Tenant Application Tenant n Sig n In Corporate LDAP With applications moving outside of customer premise, corporate users are forced to have multiple identities one corporate and other in-cloud application identity. This poses a security problem for customers since a person moving out of the company still has access to corporate data. Therefore it becomes necessary to allow identity to be federated from the corporate context.

Therefore the application has to be ready to De-Couple Identity Management and Authentication Support delegation of IdM and Authentication to corporate systems through established standards like SAML. 15 Configuration Over Customization In order to drive efficiency, an application must standardize its features. However this results in not being able to accommodate customers with alternate business processes. This results in an architectural requirement: How to support customization via configuration? Database Allow extension of existing entities Business Logic Business Logic Templates Allow pluggable business logic. Allow small changes to business process UI Metadata driven UI Customize Look and Feel Layout

Content 16 UI Customization Depending on requirements UI customization is done at various depths Look and Feel The ability to change the font, color and style of existing UI Layout The ability to switch component layouts Content The ability to choose what content goes where. Two Approaches Both approaches require a metadata layer that can understand the customization done be specific tenants. UI Rendering must take into account a standard layout as well as the metadata for rendering. Accommodate tenant specific UI Data models that can extensions to standard data models. 17 Business Logic & Database Customization Business Process Customization Database Customization Enable an application to be flexible in allowing changes to business logic Ability to extend the schema as per specific

requirement Allow different workflows to be configured per tenant. In the Shared Database Separate Schema and Separate Database pattern, this becomes trivial as the customization can be done directly. Reference: Reference: Multi Multi Tenant Data Architecture, Architecture, At the application design level Frederick Frederick Chong, Chong, Follow a highly de-coupled, Gianpaolo Gianpaolo Carraro, Carraro, and and pluggable component based design. Roger Roger Wolter Wolter

Microsoft Microsoft Corporation Corporation Standard IoC Pattern to plug new implementations At the functional level Decide on the smaller variations that a business process/logic can take. Make these configurable. Allow ability to plugin newer processes as the application evolves. Spring Spring Accommodate generic data models during processing to cater to extended schemas Again a metadata layer is required to understand the configuration done by tenants at the business process level as well as newer business process that is available. 18 In the Shared Database-Shared Schema, the following approaches are standard To have a pre-determined set of fields for specific data models that can be used as

extensions. To have a generic extension schema that can accommodate customization to any entities and a data access and business logic layer that can bring in the tenant context when querying. Scalability Data In case of a RDBMS, Shared Database Shared Schema use partitioning by tenantid (SHARD) Give a thought about NoSQL Databases if dealing with multiples of TB of data(ACID vs BASE) Hadoop Hadoop HBASE Clustering Make services as stateless as possible. Session Replication is a nightmare. Application Server Avoid file system for data. Use a central datastore De-Coupled Components

Conceptualize application features that can be de-coupled and scaled separately. Allows a resource hogging feature to be separated out and scale strategy planned differently. Cache data where possible (memory IS cheap) Plan for failure Auto Recovery. With the current scope of browser capabilities (HTML5) pushing state to the browser has become easier. UI Also frameworks like GWT has enabled complex applications to sit on the client side. For applications using more sophisticated RIA clients (OpenLAZLO, FLEX or Silverlight), the same principle applies 19 Questions? 20

Recently Viewed Presentations

  • M6:LSN2 Interpreting Rate of Change Activating Prior Knowledge

    M6:LSN2 Interpreting Rate of Change Activating Prior Knowledge

    M6:LSN2. Interpreting Rate of Change. CFU. Concept Development. Module. Page 8. Linear functions are defined by the equation of a line. The graphs and the equations of the lines are important for understanding the relationship between the two variables represented...
  • Analysis of Semi-Volatile Leachables by Dispersive Liquid Liquid

    Analysis of Semi-Volatile Leachables by Dispersive Liquid Liquid

    DLLME on Aqueous Samples. DLLME on IPA Samples. Conclusions. Although more straightforward for aqueous sample types, DLLME has successfully been applied to the analysis of biopharmaceutical and other complex sample systems which are becoming more popular within the pharma industry.
  • I Timothy 4 -

    I Timothy 4 -

    The Doctrine of Godliness (Experiential Sanctification). Definition. a) Godliness is a word in the New Testament derived from two different Greek words: EUSEBEIA and THEOSEBEIA. Both mean duty toward God and both are technical for the balance of residency in...
  • CMSC420: Splay Trees - University Of Maryland

    CMSC420: Splay Trees - University Of Maryland

    CMSC420: Splay Trees Kinga Dobolyi Based off notes by Dave Mount What is the purpose of this class? Data storage Speed Trees Binary search tree Expected runtime for search is O(logn) Could degenerate into a linked list O(n) AVL tree...
  • Multi-Layer Perceptron (MLP)

    Multi-Layer Perceptron (MLP)

    A weight is simply a floating point number and it's these we adjust when we eventually come to train the network. * Neural networks A neuron can have any number of inputs from one to n, where n is the...
  • PhD Értekezés

    PhD Értekezés

    A hallgatók adataiban a hallgató Neptun-kódja, és a tantárgyak adataiban a tárgyat felvett hallgató Neptun-kódja mint kapcsolat-tartó mező lehetővé teszi a tantárgyi névsor, vagy a hallgatói elektronikus index létrehozását) MS Access = Windows alatt futó relációs adatbázis-kezelő alkalmazás * Az...
  • The Team - CareSearch

    The Team - CareSearch

    In people with chronic refractory breathlessness: Should we pursue the investigation of peripheral opioid receptors with interventions such as nebulised opioids? Shoud we consider studying the new compound pharmaceuticals (opioid agonist / peripheral opioid antagonists such as Targin R)? So...
  • Some Graph Problems LINIALS CONJECTURE Backgound: In a

    Some Graph Problems LINIALS CONJECTURE Backgound: In a

    LiniAl's Conjecture. Backgound: In a partially ordered set we have Dilworth's Theorem;. The largest size of an independent set (completely unordered set) is the smallest number of blocks in a partition of the elements into completely ordered sets.