[ https://issues.apache.org/jira/browse/OAK-3003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
angela updated OAK-3003: ------------------------ Attachment: group_cache_in_userprincipalprovider.txt OAK-3003.patch initial proposal including some preliminary figures from the {{LoginWithMembershipTest}}. [~djaeggi], [~chaotic], would it be possible to look at the proposal? the goal was to tmp. cache group-principals as calculated upon {{PermissionProvider#getPrincipals(String)}} but making sure this is only writable by the system session compiling that list upon login. TODO: - verify proper handling of potential collisions upon concurrent login - verify there is _really_ no way to exploit this - verify behavior in clustered environment. however, before investing a lot of effort, i would be glad to get feedback from my fellows in the security team :-) > Improve login performance with huge group membership > ---------------------------------------------------- > > Key: OAK-3003 > URL: https://issues.apache.org/jira/browse/OAK-3003 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core > Reporter: angela > Assignee: angela > Attachments: OAK-3003.patch, group_cache_in_userprincipalprovider.txt > > > As visible when running {{LoginWithMembershipTest}} default login performance > (which uses the {{o.a.j.oak.security.principal.PrincipalProviderImpl}} to > lookup the complete set of principals) suffers when a given user is member of > a huge number of groups (see also OAK-2690 for benchmark data). > While using dynamic group membership (and thus a custom {{PrincipalProvider}} > would be the preferable way to deal with this, we still want to optimize > {{PrincipalProvider.getPrincipals(String userId}} for the default > implementation. > With the introduction of a less generic implementation in OAK-2690, we might > be able to come up with an optimization that makes use of the very > implementation details of the user management while at the same time being > able to properly secure it as we won't need to extend the public API. -- This message was sent by Atlassian JIRA (v6.3.4#6332)