Hi Andrey, I will probably post on here, on LinkedIn <https://www.linkedin.com/pulse/more-secure-web-applications-orientdb-bruce-ashton> and update the OdbResource project on Github <https://github.com/skwidge/OdbResource>. I think the realm and resource factory will still be useful.
On Saturday, 3 October 2015 00:50:07 UTC+13, Andrey Lomakin wrote: > > 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 <[email protected] > <javascript:>> 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 <[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] <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.
