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]> 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]. > 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.
