> On Dec 3, 2015, at 2:31 AM, Jan Sindberg <[email protected]> wrote: > > I will look into it. The interesting point for us is probably initialization > . Since it is an extension point in the Fortress "framework", I think that it > is as it should be .... > Before I dive into this, could you take a look at my other question regarding > Cache lifecycle? It seems to me that the cache has very little impact on > system runtime performance of an RBAC guarded application. It might help > Fortress Commander - but my concern is about the many permissions that is > constantly checked in the application. I don't see any slowness but I might > have to deal with network latency in real production environments.
Fortunately permission checking is the fastest operation in this system. It requires one permission search (really a ‘read’ because it is an indexed search), and if you have enabled audit - one compare - to force the slapo access log to store the result. With Fortress core I recently benchmarked around 10K/second against OpenLDAP. If speed is paramount you might be interested in the accelerator, which was discussed at ldapcon a couple of weeks ago: http://ldapcon.org/2015/wp-content/uploads/2015/09/McKinney-Openldap-Accelerator-LdapCon-2015-v4.pdf Its measured benchmark is around 20K/second permission check ops. As for the question is caching required for runtime (as opposed to administration time)? The answer is ‘yes’ if you are using hierarchical roles (RBAC1) or dynamic separation of duty (RBAC3) in your decisions. Both data structures are maintained in the cache for performance reasons. There is an option to turn off caching for DSD but that would hurt performance as the system would have to repeatedly look up those data structs in the directory. Perhaps there is a happy medium. We’ll need to think about that.
