Building Multi Tenant Java Applications Rajesh Venkatesan Senior Architect, HCL Technologies rajeshvn@hcl. com
Multi Tenancy – An Overview Ability to cater to multiple customers using a shared instance of Software/Hardware What? ¡ Time Share ¡ ASP ¡ End User Web Apps When? Why? How? That’s what this session is about 2 ¡ Inability of SOHO and SMB segments to adopt IT ¡ Non IT Businesses getting entrenched in managing IT
Multi Tenancy Impact in the real world Shared Infrastructure – Lower Cost Configuration over Customization – Driving Standardization Higher Complexity of Construction Dedicated Infrastructure – Higher Cost Tailor Made Construction – relatively easy Single Vs Multi. Tenancy Heavy Customization - Support Non Standard Requirements Higher Scale – Lower Cost Shared Vulnerability Shared Upgrades Scalability is bound to target customer size Minimized Vulnerability Customized Upgrades 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 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 Easier to Maintain Allows Customization Higher Security Easy DB Upgrades High Cost to Customer Shared Database – Separate Schema Trade Off Considerations Easier to Maintain ¡ Compliance/Regulatory Allows Customization Relatively Higher Security Slightly Complex DB Upgrades Average Cost to Customer ¡ Cost § Operations § Time to Market ¡ Liability Shared Database – Shared Schema Lowest Cost Complex Upgrade Process Availability impacts multiple customers Data Security delegated to application layer 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 a JDBC Perspective this implies different connection strings based on the customer. ¡ Typical Tenant Context is set by an intercepting filter and obtained at the DAO layer possibly via a Thread. Local variable ¡ For Hibernate implement a Tenant aware Shared Database Shared Schema Connection. Provider and switch off the second level cache. 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 Hibernate ¡ Abstract Multi Tenancy concern to the Data Access Layer and write business logic without tenant context. ¡ Use Filters ¡ Use Hibernate 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 ¡ Well Defined Standard q WSS for Multi Tenant Security (Username/Token, X 509 – Tenant Certificate, SAML, Kerberos) Axis, XFire ¡ Standards Based ¡ High Security ¡ Multi Tenant Aware WSS 4 J ¡ REST ¡ Easy Integration q Simplicity q 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 q Data can pushed to waiting WS endpoints q Publish Standard Web Service Interfaces that customers can implement. q Multi Tenant aware integration layer appropriately calls out the tenant specific interface. q Problem with availability of customer endpoints ¡ Push Asynchronous q Expose Secure Asynchronous Messaging Infrastructure. q Heavy Vs Light Weight Events v 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. v Push the entire message with all relevant information. The Infrastructure is absolutely secure. q The messaging infrastructure takes responsibility of ensuring delivery. 10
Security Facets of Security Physical 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 q Trade. Offs v Database functions cannot be applied on encrypted fields v 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 (http: //www. OWASP. org) is a good place to look. § A 1: Injection § A 2: Cross-Site Scripting (XSS) § A 3: Broken Authentication and Session Management § A 4: Insecure Direct Object References § A 5: Cross-Site Request Forgery (CSRF) § A 6: Security Misconfiguration § A 7: Insecure Cryptographic Storage § A 8: Failure to Restrict URL Access § A 9: Insufficient Transport Layer Protection § A 10: 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 n I Sig 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 Id. M 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 Template/Skin Based • Allow tenants to choose different themes and ability to write new themes is restricted but possible. • Standard mechanism followed by most websites (Blogger, Wordpress, Liferay) Complete Customization • Allows tenants to customize the UI as per their requirements. • How much they can customize is left to the application. • Drag and Drop UI to Customize ¡ 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. ¡ At the application design level q Follow a highly de-coupled, pluggable component based design. q Standard Io. C Pattern to plug new implementations Reference: Multi Tenant Data Architecture, Frederick Chong, Gianpaolo Carraro, and Roger Wolter Microsoft Corporation ¡ At the functional level q Decide on the smaller variations that a business process/logic can take. Make these configurable. q Allow ability to plugin newer processes as the application evolves. 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 q To have a pre-determined set of fields for specific data models that can be used as extensions. q 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 No. SQL Databases if dealing with multiples of TB of data(ACID vs BASE) ¡ Clustering § Make services as stateless as possible. Session Replication is a nightmare. § Avoid file system for data. Use a central datastore Application Server Hadoop HBASE ¡ 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 (HTML 5) 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 (Open. LAZLO, FLEX or Silverlight), the same principle applies 19
Questions? 20
Скачать презентацию Building Multi Tenant Java Applications Rajesh Venkatesan Senior
b896959902747c0b5a1759e49b18efe5.ppt