Hi Andrey, Thanks, that is a solution I had completely missed, I will try that. It looks like I wasted a bit of time there writing my dodgy connection pool :-/
I notice OPartitionedDatabasePoolFactory is not even mentioned in the manual and OPartitionedDatabasePool is mentioned only briefly. When I get an opportunity I might write something up and post it here. I think this is a use case other people might be interested in. On Wednesday, 30 September 2015 03:26:13 UTC+13, Andrey Lomakin wrote: > > > Hi , > Your solution is really interesting and deserves to be published to wide > audience . > > But problem with creation of OrientGrah instances with many users have > already been solved by us . > > You see OrientGraph is merely think wrapper on ODatabaseDocumetTX instance > , creation of which I agree is expensive task . To solve problem when you > have millions of users in database we have created > OPartitinedDatabasePoolFactory which is lock free LRU list of connection > pools for each user , each connection pool not only lock free but for many > classes wait free because it tries to partition load between active CPU > cores ( indirectly of course ) . According to our benchmarks acquring of > connection from this pool requires nanoseconds . When you acquire database > instance you merely wrap it in OrientGraph instance which is cheap > operation . Could you try this approach and send us feedback ? > > On Sun, Sep 27, 2015, 12:55 Argh Skwidge <[email protected] <javascript:>> > wrote: > >> I see an opportunity to use OrientDB to help developers write more secure >> web applications using record level security. There is a gap in the way >> authentication is done in OrientDB that would have to be bridged for this >> to really work well though. >> >> I've written a connection pool resource >> <https://github.com/skwidge/OdbResource/releases/tag/v1.0> for Tomcat as >> a working demonstration. It's not perfect implementation but it illustrates >> a possibility that the existing OrientDB pools don't quite support. >> >> Essentially the idea relies on record level security and a customised >> inheritance model for Odentity class and sub-classes. >> >> A Graph User Model >> >> >> There are six classes that are of interest to us when defining the user >> model in an OrientDB graph database. The classes and their relationships in >> a freshly created graph database are shown below. As you can see OUser and >> ORole both extend OIdentity, but none of the other classes have any >> particular relationship. >> >> OUser and ORole must extend OIdentity, in order to be part of the >> OrientDB security model. But wouldn't it be useful if our users could part >> of a graph? The easiest way to achieve this is to let OIdentity extend V. >> Now Our users can also be nodes in a graph. >> >> >> Just as a note, OrientDB versions 2.1 and later allow multiple >> inheritance, which would allow OUser or ORole to extend both OIdentity and >> V. This would allow more flexibility in how one structures this. >> >> >> We also would like to apply record level security to all the elements of >> our graph, including the users. We can do this by letting V, and possibly >> also E, extend ORestricted, as recommended in the manual >> <http://orientdb.com/docs/last/Database-Security.html#record-level-security>. >> >> Now our class diagram looks like this: >> The Benefits >> >> >> At this point database users are first class citizens of our graph and >> can be queried like any other graph component. The records they create >> (including new roles and users) can be governed by record level security. >> >> >> Now let's say we create a web application that allows users to sign up >> and log in. We still need to write the user interface for these functions, >> but we no longer have to develop a user model, permissions model, etc. We >> get these for free. >> >> >> Any new records created by a user are only available to that user by >> default, so long as we ensure those records extend ORestricted. If we want >> to make the records more generally available we must do so explicitly >> either by policy or specific action. New restricted records are created >> secure by default. >> >> This directly mitigates the risk of one of the most common web >> application vulnerabilities - insecure direct object references >> <https://www.owasp.org/index.php/Top_10_2013-A4-Insecure_Direct_Object_References>. >> >> Every reference to a vertex or edge in our graph gets access checked for >> free. >> >> >> It indirectly mitigates some of the risk of broken authentication and >> session management >> <https://www.owasp.org/index.php/Top_10_2013-A2-Broken_Authentication_and_Session_Management>, >> >> in as much as it allows this functionality to be delegated to the database. >> Authentication is handled directly by the database. Session management >> remains the responsibility of the web application, but this can be >> delegated to the container. Using OdbRealm and OdbResource, authentication >> and session management become a task of configuration rather than coding. >> >> >> There is a significant non-security related benefit here as well. >> Developers still get tasked with writing boilerplate authentication and >> authorisation management code for far too many web applications. Having >> this provided is a real timesaver. >> >> >> It potentially mitigates some of the risk of missing function level >> access control >> <https://www.owasp.org/index.php/Top_10_2013-A7-Missing_Function_Level_Access_Control>. >> >> It does this by protecting access to the underlying data. For example, a >> blog user might have write access to their own posts but only read access >> to another user's posts. A malicious user might find a way to invoke edit >> functionality on another user's blog, but the edit would still fail because >> of access checks. >> >> >> The Risks >> >> >> There is a flip-side to making all your users database users. An OrientDB >> database engine usually listens on a couple of ports and a malicious user >> could potentially log in on any of them and execute arbitrary queries, if >> they were to gain network access and the credentials of any user. The >> queries would still be governed by the same security model though, and >> sensible firewall, network and database configuration should provide >> sufficient protection from this. >> >> Scalability >> >> >> The biggest issue is the potential for scalability issues due to the >> OrientDB connection and authentication model. >> >> >> OrientDB encapsulates a connection to a graph database with an instance >> of the class OrientGraph. The credentials must be passed in at instance >> construction. This means at least one OrientGraph instance must be created >> for each logged in user. This will eventually hit limits with large numbers >> of users. >> >> >> Connection Pooling >> >> >> If this were a traditional DB user model, with a small number of database >> users servicing all web users, connection pooling would be a relatively >> simple task. But here every logged in web user requires at least one >> distinct OrientGraph instance, at least for the duration of a given >> request. Creating a new OrientGraph instance is a relatively expensive >> operation. >> >> >> Embedding the database in the web application goes some way to solving >> this problem by removing the need for any kind of socket resource. However >> we still want to avoid creating a new OrientGraph instance for every >> request. >> >> >> I have not done any benchmarking on OrientDB to see just how many >> concurrent OrientGraph instances can be used, nor am I aware of any >> benchmarking by anyone else, including Orient Technologies >> <http://orientdb.com/>. >> >> >> Solutions >> >> >> <https://github.com/skwidge/OdbResource> >> >> The OdbResource library <https://github.com/skwidge/OdbResource> >> provides a pool for OrientGraph instances, but it is a kludge. OrientGraph >> instances are created for a particular user and can only be used by that >> user. They are recycled across requests, but once the number of logged in >> users exceeds the maximum number of connections in the pool, existing >> OrientGraph instances must be constantly destroyed so that new instances >> can be created for other users. What it mostly does is allow us to tune the >> total number of OrientGraph instances per application (and per user.) This >> at least allows a web application to fail more gracefully. >> >> >> What is required is the ability to cheaply re-authenticate existing >> OrientGraph instances with new sets of credentials. This would allow the >> creation of a proper connection pool. But this solution requires a patch to >> OrientDB. It can't be achieved just by library interacting with OrientDB's >> public API <http://orientdb.com/javadoc/latest/>. >> >> >> So this post is in part a plea to Orient Technologies >> <http://orientdb.com/>, the company behind OrientDB, to support these >> ideas. A better solution than OdbResource requires changes to the OrientDB >> codebase. I would like to write a patch, but there would be a considerable >> amount of work involved in producing and then maintaining it. It would help >> a lot to know Orient Technologies were interested in supporting this model >> of use of OrientDB. >> >> >> -- >> >> --- >> You received this message because you are subscribed to the Google Groups >> "OrientDB" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > -- --- You received this message because you are subscribed to the Google Groups "OrientDB" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
