Swing Client Security
From iDempiere en
Because of an small [discussion about the two different idempiere clients] (swing and zk) I had some thoughts about the security of the Swing client.
The swing client keeps a (simply obscured password) in his configuration file. With this password you can access the whole database. This is a security issue. What can we do about this?!?
I think the complex of Swing <-> Zk and his issues is an often discussed issue. I did this page to keep my knowledge and to let the next discussion begin on the shoulders of the last. :-)
See also Comparison of Clients.
possible solutions
- solutions on database level
- using the grant access rights security - but this is only per table: not very secure for our purpose
- using [partitioned tables] in postgres - with this we could divide tables by client and/or by organization
- using a kind of [Row Level Security] would be better. [It seems] that this will be implemented in PostgreSQL 9.3. I do not really understand why [rules], [Views] and [Triggers] may not do it. And I have no clue what that means for performance (It will be nothing comared to the Java persistence Layer but I don't know what happens to bulk operations and direct SQL queries in the code).
- solutions in the Swing Client
- We could connect an application server and get a one-time password (like a ticket). The server maintains a group of postgres Users on-the-fly (database security is the same as now but there is no openly accessable password file - we have to defend the persistence code in the Client, perhaps with a signed OSGi plugin or such).
- solutions with a new Client
- What is better with swing? (It is much faster than Zk in reaction on clicks.)
- If Zk would cache more data it would react much faster (CarlosRuiz mentioned that a GWT Client would work in such a way)
- We have to move the border of separation between server and client.
- Nobody has (yet?) the time, resources and will to build a complete new client architecture
- One way: another technology just where needed (for data entry, POS, etc.)
- Perhaps we could integrate a Java applet into the Zk.
- IMHO this applet can not be the whole now used Swing Client. Such a thing will not integrate well. It has to be a three-tier-client with it's own local data cache.
- What about installing Zk local on the same machine as the browser (to speed it up). Can we use many servers on one database?
chat between tbayen and CarlosRuiz at 2013-01-09
Jan 09 20:41:26 <CarlosRuiz> you still use swing - right? Jan 09 20:48:17 <tbayen> About swing... Jan 09 20:48:53 <tbayen> I like swing for personal reasons (i am used programming it). After reading the thread in idempiere group I decided to give the zk a try. Jan 09 20:50:16 <tbayen> I am sorry - but ZK feels terrible slow. I use it from a server in my LAN and every click needs a bit of time where swing needs zero time. It makes much less fun than swing. Jan 09 20:50:54 <tbayen> I can not switch between tabs fast just to look for a small piece of information like I did in Swing. Jan 09 20:50:55 <CarlosRuiz> sounds weird - on a LAN must be very fast Jan 09 20:51:23 <tbayen> Clicks on zk need between 0.5 up to 2 seconds. Jan 09 20:52:19 <tbayen> This is not much for ebay or amazon. But swing is much faster. And if you want to do really much work this can be a big difference. Jan 09 20:54:15 <tbayen> Our old ERP is a DOS application with a Novell Database. It answers like a flash. It is a question of acceptance of my employees that this "new weird thing" is not even slower than the old DOS program. Jan 09 20:55:14 <possy> tbayen, I doubt that you will ever find a current app that is as fast as a btrieve based DOS app. Jan 09 20:55:40 <possy> It is called progress. Jan 09 20:55:56 <possy> That's why you should by shares in coffee selling companies Jan 09 20:56:14 <tbayen> But swing feels fast. All data in the gui is cached locally. ZK does a roundtrip for every click afaiu. Jan 09 20:57:20 <tbayen> Hmmm... that may be the real reason that I decided to sell coffee last year. :-) I did not understand my own deep psychology! Jan 09 20:58:21 <tbayen> To say what I wanted to sayto CarlosRuiz (and the idempiere world): I want to defend Swing! Jan 09 20:59:13 <CarlosRuiz> you don't need to convince me about the goods of a client/server app Jan 09 20:59:21 <CarlosRuiz> my real complain is about security of swing client Jan 09 21:00:02 <tbayen> I think about this security issue since I read your post. You were the only with a real reason against swing in this thread. Jan 09 21:01:08 <tbayen> I have no experience with this but in theory Postgres could do that for us with massive use of triggers and such. But it will be a performance desaster, or WDYT? Jan 09 21:50:15 <CarlosRuiz> nope - seems like my connection was dropped Jan 09 21:50:24 <CarlosRuiz> after I wrote "some clients decided the probability is little" Jan 09 21:50:57 <CarlosRuiz> I remember there were proposals to make that password safe - i.e. creating database users per each adempiere user and assigning db permissions Jan 09 21:51:41 <tbayen> I have not enough experience with this to oversee the performance issue with this but it would be the best solution. Jan 09 22:09:43 <tbayen> Can you tell about the performance impact? Is it acceptable? Jan 09 22:12:35 <tbayen> I had another idea: We could get the actual db user & pw from a running application server that creates postgres users on demand. So the password will not be stored locally. But this user has still all privileges. You could hack this perhaps by looking into a core dump of idempiere or - best - by having your own version of idempiere. Jan 09 22:14:12 <tbayen> It must be possible to encrypt the pw inside the java vm. And we could find a way to calculate a hash sum of the running osgi database plugin to cryptograpically tell the server we are not hacked. Jan 09 22:15:49 <CarlosRuiz> I've never been too prone to multiple db users approach Jan 09 22:16:06 <CarlosRuiz> but that's precisely the problem of client/server apps Jan 09 22:16:56 <CarlosRuiz> maybe your idea of those on-the-fly users could be worthy to explore Jan 09 22:17:16 <tbayen> What is the reason for all these user rights stuff in the database servers when not to use it for that?!? Jan 09 22:17:16 <CarlosRuiz> like creating a user just for the session and then expiring it Jan 09 22:17:23 <tbayen> Like a ticket Jan 09 22:17:39 <CarlosRuiz> the app servers replaced the security layer of dbs Jan 09 22:19:01 <tbayen> The bad side of my solution is that in the last consequence the created "ticket user" will have all rights. We have to defend him in the client VM and in the connection. Jan 09 22:19:52 <tbayen> OSGI might be the solution because we only have to defend one plugin. Jan 09 22:22:42 <CarlosRuiz> on the other hand - whenever you raise that topic - conclusion is the same -> is too complex to solve that when security issues are already solved on three-tier applications Jan 09 22:23:09 <CarlosRuiz> or in other words - zkwebui doesn't have that problem - why I would be motivated to solve that on a legacy client/server architecture ;-) Jan 09 22:23:19 <tbayen> Do you want to rewrite adempiere as a three-tier app? Jan 09 22:24:42 <CarlosRuiz> well - I would say is not 100% 3-tier - but many parts of idempiere are Jan 09 22:25:01 <CarlosRuiz> there is clear distinction between view layer - business layer and data layer Jan 09 22:25:01 <tbayen> I feel strong that swing has advantages over zk. It feels much faster. Jan 09 22:26:41 <CarlosRuiz> I think that's the main advantage - quick entry - that's why POS on supermarkets cannot be web Jan 09 22:26:55 <CarlosRuiz> but that is for specific usages Jan 09 22:27:09 <CarlosRuiz> I mean - you don't need quick entry in every window Jan 09 22:27:24 <CarlosRuiz> just on some high-volume entry work windows Jan 09 22:27:30 <tbayen> I don't believe that only personnel in the supermaket wants a fast gui. Jan 09 22:28:09 <CarlosRuiz> is like comparing using gmail on thunderbird against gmail on a browser Jan 09 22:28:50 <tbayen> An idea might be a three-tier swing client. business logic in the server but gui and data cache in the client. Jan 09 22:29:28 <tbayen> I can not estimate how much code we could reuse for that. I am afraid not that much. Jan 09 22:30:03 <tbayen> I never looked into the zk code but it must be written this style, mustn't? Jan 09 22:30:33 <CarlosRuiz> which style? Jan 09 22:32:10 <tbayen> There is a different piece of code running on the client (javascript/zk) and one piece running on the server. There is a clean border between them. This is not the case with Swing. Jan 09 22:33:21 <CarlosRuiz> hmm - indeed zk is mostly running on server Jan 09 22:33:36 <CarlosRuiz> GWT is more like you described - running some parts on the browser Jan 09 22:33:42 <CarlosRuiz> but zk is server-centric Jan 09 22:34:17 <tbayen> That seems to cause my performance problem: Every small click has a round-trip. Jan 09 22:35:07 <tbayen> It would be nice if the programmer could decide which parts are where so we can cache what is needed for fast response. Jan 09 22:35:47 <CarlosRuiz> saving local data - that opens a new problem about synchronization Jan 09 22:36:00 <CarlosRuiz> there is a guy trying to do an off-line adempiere on chrome Jan 09 22:37:16 <tbayen> Swing client does this all the time. Or how are the gui tables done in memory? It is no problem. Sometimes it says that another user changed my data. That can happen with zk also Jan 09 22:37:37 <CarlosRuiz> but I don't think that approach will work - on an ERP Jan 09 22:37:44 <CarlosRuiz> nope - swing is always reading db Jan 09 22:38:18 <CarlosRuiz> there is a cache for some tables - but precisely that cahce present problems Jan 09 22:39:07 <tbayen> If I scroll throug a long list Swing does not re-read the table... I did this before and it is a bit slower. Adempiere Swing is very fast. It must be cached in memory. Jan 09 22:39:10 <CarlosRuiz> like IDEMPIERE-491 - hengsin recently implemented a distributed cache with hazelcast to try to solve that Jan 09 22:40:27 <CarlosRuiz> yes - some lookups are kept in memory too - and when you open a window and go grid - that gridtable is on memory until you requery Jan 09 22:40:38 <CarlosRuiz> same for zk Jan 09 22:41:17 <CarlosRuiz> the difference is because on zk server is solving the render of the page - swing render internally Jan 09 22:41:18 <tbayen> I read IDEMPIERE-491. Kind of these problems will always stop us of scale too big. How many users can one idempiere server serve?!? Have you seen a Jan 09 22:41:24 <tbayen> limit? Jan 09 22:43:33 <tbayen> The caches you speak of are internal caches of the PO? That problem is the same if you use two swing clients??? Jan 09 22:44:08 <CarlosRuiz> yes Jan 09 22:44:36 <CarlosRuiz> in my tests the hengsin changes solved that Jan 09 22:45:47 <tbayen> If he solved that so we can use more than one idempiere instance with swing and zk there is no reason that a three-tier-swing with partly local caches will not also work. Jan 09 22:47:15 <tbayen> I will conclude: There are reasons to move the border between server and client work. ZK does not the best. current Swing does not the best. Jan 09 22:47:32 <tbayen> Has somebody the time to begin a new client? .... :-( Jan 09 22:48:51 <tbayen> A solution on the database level will be not so elegant but faster to do. Jan 09 23:00:38 <CarlosRuiz> I've seen other approaches for clientes Jan 09 23:00:41 <CarlosRuiz> clients Jan 09 23:01:17 <CarlosRuiz> 3e from Poland developed a pascal client - using webservices Jan 09 23:01:41 <CarlosRuiz> there was also some guys doing an adobe flex client - but never contributed the code Jan 09 23:01:59 <CarlosRuiz> supposedly ngigi waithaka developed the gwt client - but is charging for that Jan 09 23:02:39 <CarlosRuiz> I like to see options - but I'm pretty comfortable with zk performance and richness of features Jan 09 23:03:03 <tbayen> I had the idea of java applets that you can choose as a view inside the zk. With that you could have the best of both worlds. But for that we need a not so fat swing client. Jan 09 23:03:13 <CarlosRuiz> but I know but for some quick entry POS - maybe a different approach is needed - like the OB POS offline integration Jan 09 23:03:34 <CarlosRuiz> and there is now the phones and tablets Jan 09 23:03:45 <CarlosRuiz> they serve also different purposes and the approach is different Jan 09 23:04:45 <tbayen> Yes - for all these new platforms web will be an easier path than a desktop library like swing.
