Hi sure, If your result will be successful maybe you will consider write a blog entry about this user case ?
On Fri, Oct 2, 2015 at 1:38 PM Argh Skwidge <arghskwi...@gmail.com> wrote: > 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 <arghs...@gmail.com> 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 orient-databa...@googlegroups.com. >> >> >>> 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 orient-database+unsubscr...@googlegroups.com. > 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 orient-database+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
