Presentation on theme: "Building Multi Tenant Java Applications"— Presentation transcript:
1 Building Multi Tenant Java Applications Rajesh VenkatesanSenior Architect, HCL Technologies
2 Multi Tenancy – An Overview Ability to cater tomultiple customersusing a shared instanceof Software/HardwareWhat?Why?How?When?Time ShareASPEnd User Web AppsInability of SOHO and SMB segments to adopt ITNon IT Businesses getting entrenched in managing ITThat’s what thissession is about
3 Multi Tenancy Impact in the real world Shared Infrastructure – Lower CostDedicated Infrastructure – Higher CostHigher Complexity of ConstructionTailor Made Construction – relatively easyConfiguration over Customization – Driving StandardizationHeavy Customization - Support Non Standard RequirementsSingle Vs MultiTenancyHigher Scale – Lower CostScalability is bound to target customer sizeShared VulnerabilityMinimized VulnerabilityShared UpgradesCustomized Upgrades
4 Architectural Facets of Multi Tenancy in the Software World Virtualized HardwareDatabaseApplication ServersInboundOutboundShared InfrastructureIntegrationConfiguration over CustomizationSecurityData SecurityApplication SecurityStandardization ofUIData ModelBusiness Logic
5 Shared Infrastructure – Database Typically Multi Tenancy at the database level has 3 standard patternsSeparate DatabaseTraditional – Isolated Database Instance Per CustomerShared Database Separate SchemaCustomers get their own schema but are co-hosted in the same databaseShared Database – Shared SchemaDrives the highest efficiency. All Customers data is stored in the same database and schema with a tenant id qualifierIsolatedSharedIsolatedSharedShared SchemaSeparate SchemaSeparate DBSource: Multi Tenant Data Architecture, Frederick Chong, Gianpaolo Carraro, and Roger Wolter Microsoft Corporation
6 Database Multi Tenancy Patterns – Pros and Cons Separate Database Easier to Maintain Allows Customization Higher Security Easy DB Upgrades High Cost to CustomerShared Database – Separate SchemaTrade Off ConsiderationsCompliance/RegulatoryCostOperationsTime to MarketLiability Easier to Maintain Allows Customization Relatively Higher Security Slightly Complex DB Upgrades Average Cost to CustomerShared Database – Shared Schema Lowest Cost Complex Upgrade Process Availability impacts multiple customers Data Security delegated to application layer
7 Database Multi Tenancy Implementation Isolated Database and Shared Database – Separate SchemaFrom 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 ThreadLocal variableFor Hibernate implement a Tenant aware ConnectionProvider and switch off the second level cache.Standard Data Access simply returns the appropriate connection based on tenant contextShared Database Shared SchemaApproach 1Business Logic and Data Access is aware of multi tenant context and therefore query appropriatelyPros – Easy to buildCons – High Probability of bugs leading to data leakageApproach 2Abstract Multi Tenancy concern to the Data Access Layer and write business logic without tenant context.Data Access Layer automatically adds tenant context to all data callsFor HibernateUse FiltersUse Hibernate Shards
8 IntegrationTypical integration concerns when applications move out of customer premises includeHow can I receive notificationHow do I orchestrate my business processHow can I push data to the applicationIs there standard integration?Familiar? SOA?
9 Integration – ContdFundamentally the application must support well defined interfaces for inbound Integration as well as Outbound IntegrationInbound IntegrationImplementationExpose “services”Technology IndependentStandards BasedHigh SecurityMulti Tenant AwareSOAPWell Defined StandardWSS for Multi Tenant Security (Username/Token, X509 –Tenant Certificate, SAML, Kerberos)RESTEasy IntegrationSimplicitySecurity to be built on top.Axis, XFireWSS4JJAX-WS
10 Integration – Contd Outbound Integration Allow Tenants to register for integration events.Push Vs PullPush – SynchronousData can pushed to waiting WS endpointsPublish 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 endpointsPush AsynchronousExpose Secure Asynchronous Messaging Infrastructure.Heavy Vs Light Weight EventsFor 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.
12 Data Security Data at Rest Data in Transit JCA/JCE Use tenant specific encryption when required. Decouple encryption awareness from the data layer allowing data leaks to still be harmlessTradeOffsDatabase functions cannot be applied on encrypted fieldsPerformanceTokenization of Data – Only a token reference is stored in the database. Actual data has to come from a high security data protection serverData in TransitUse Secure means of transfer (https) and add authentication/ authorization layer on top.Use In Wire Encryption for highly critical dataJSSE
13 Application SecurityApplication 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.A1: InjectionA2: Cross-Site Scripting (XSS)A3: Broken Authentication and Session ManagementA4: Insecure Direct Object ReferencesA5: Cross-Site Request Forgery (CSRF)A6: Security MisconfigurationA7: Insecure Cryptographic StorageA8: Failure to Restrict URL AccessA9: Insufficient Transport Layer ProtectionA10: Unvalidated Redirects and Forwards
14 Application Security – Contd Some of the security best practices for applicationsEncrypt 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 permissionsAll Inbound and Outbound interface points must be secured by default. (SSL)Additional Tenant Aware Security measures likeTenant Specific Certificates
15 Application Security – Federated Identity Tenant 1Sign InCorporate LDAPMulti Tenant ApplicationTenant nSign InCorporate LDAPWith 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 toDe-Couple Identity Management and AuthenticationSupport delegation of IdM and Authentication to corporate systems through established standards like SAML.
16 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?DatabaseAllow extension of existing entitiesBusiness LogicBusiness Logic TemplatesAllow pluggable business logic.Allow small changes to business processUIMetadata driven UICustomizeLook and FeelLayoutContent
17 Complete Customization UI CustomizationDepending on requirements UI customization is done at various depthsLook and Feel – The ability to change the font, color and style of existing UILayout – The ability to switch component layoutsContent – The ability to choose what content goes where.Two ApproachesBoth 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.Template/Skin BasedAllow 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 CustomizationAllows 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
18 Business Logic & Database Customization Business Process CustomizationDatabase CustomizationEnable an application to be flexible in allowing changes to business logicAllow different workflows to be configured per tenant.At the application design levelFollow a highly de-coupled, pluggable component based design.Standard IoC Pattern to plug new implementationsAt the functional levelDecide on the smaller variations that a business process/logic can take. Make these configurable.Allow ability to plugin newer processes as the application evolves.Accommodate generic data models during processing to cater to extended schemasAgain 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.Ability to extend the schema as per specific requirementIn the Shared Database – Separate Schema and Separate Database pattern, this becomes trivial as the customization can be done directly.In the Shared Database-Shared Schema, the following approaches are standardTo 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.Reference: Multi Tenant Data Architecture, Frederick Chong, Gianpaolo Carraro, and Roger Wolter Microsoft CorporationSpring
19 Scalability Data Application Server UI 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 HBASEApplication ServerClusteringMake services as stateless as possible. Session Replication is a nightmare.Avoid file system for data. Use a central datastoreDe-Coupled ComponentsConceptualize 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.UIWith the current scope of browser capabilities (HTML5) pushing state to the browser has become easier.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