[
https://issues.apache.org/jira/browse/OAK-3003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14589578#comment-14589578
]
angela edited comment on OAK-3003 at 6/18/15 10:50 AM:
-------------------------------------------------------
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.
One known drawback of this proposal is a potential information leakage about
group membership for a given user: unless group members always have read access
to the group, we may reveal information about group membership that was
accessible using regular {{Authorizable.memberOf}} calls. A possible way to
prevent this was storing the information in a hidden node (name starting with
':') which in turn results in the caching to be no longer accessible through
JCR and OAK API altogether; i.e. cleaning up or looking at it was only possible
on the NodeStore level.
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 :-)
was (Author: anchela):
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)
