You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-issues@jackrabbit.apache.org by "angela (JIRA)" <ji...@apache.org> on 2016/07/26 08:24:20 UTC

[jira] [Created] (OAK-4599) SecurityProviderRegistration fails to update config param of SecurityConfiguration(s)

angela created OAK-4599:
---------------------------

             Summary: SecurityProviderRegistration fails to update config param of SecurityConfiguration(s)
                 Key: OAK-4599
                 URL: https://issues.apache.org/jira/browse/OAK-4599
             Project: Jackrabbit Oak
          Issue Type: Bug
          Components: core
    Affects Versions: 1.5.6, 1.4.5, 1.0.32, 1.2.16, 1.1.8
            Reporter: angela


h4. Steps to reproduce

- start Oak repository in OSGi setup with additional required (custom) services that are passed to various security modules as config parameter such as e.g. {{RestrictionProvider}}, {{UserAuthenticationFactory}}, {{AuthorizableNodeName}} or {{AuthorizableActionProvider}}
- verify that the security setup contains the custom configurations
- now, force a re-registration of the {{SecurityProvider}} by changing a referenced/required security service, which is not associated with the custom configuration as specified in the initial setup
- once completed any {{SecurityConfiguration}}, that is associated with custom configuration params such as the examples listed above will no longer have the corresponding params set.

h4. Finding step by step

- {{SecurityProviderRegistration}} waits until all configured required service  references have been registered and all non-dynamic references have been resolved. 
- Once everything is resoslved the {{SecurityProviderRegistration}} looks as expected including all configuration parameters
- {{SecurityProviderRegistration}} now starts creating a new {{SecurityProvider}} instance with all the unary and required module references.
- During this step it also calls {{initializeConfiguration}} in order to have the modules populated with additional stuff from the {{SecurityProviderRegistration}} and it's here we have IMHO a bug: The {{initializeConfiguration}} will push the params from {{SecurityProviderRegistration}} to the {{SecurityConfiguration}}, while at the same time trying to merge params defined directly on the {{SecurityConfiguration}}.

h4. Explanation

In a plain Java setup as it was initial designed for the {{SecurityProviderImpl}}: The 'local' params from {{SecurityConfiguration}} need to take precedence over those present in {{SecurityProvider}}.

However, In our new, pure Osgi setup, where there is no such mixed-param-setup, we would need a mandatory overwrite of e.g. {{RestrictionProvider}}s or {{AuthorizableActionProvider}}s, because the _old_ values in the {{SecurityConfiguration}} had not been provided by it's own config but as a matter of fact refer to the old values of the {{SecurityProviderRegistration}}, which got unregistered and thus are stale service references.

h4. Potential Fixes

In any case we must have a unit-test that illustrates the problem and allows us to verify that whatever fix we apply actually addresses the problem. I will try to provide that today.

h5. Variant 1
Looking back my feeling is, that we should have moved all those extra-params that get pushed to the {{SecurityConfiguration}} as references to the modules. Not sure if/how that is feasible at the current state without risking too many compatibility issues and regressions.

h5. Variant 2
Since we no longer have a mixed java/osgi setup since the introduction of the {{SecurityProviderRegistration}} and removed the OSGi-annotations from the old (now pure java) {{SecurityProviderImpl}}, we might consider just changing the following call in {{SecurityProviderRegistration}} from:

{code}base.setParameters(ConfigurationParameters.of(parameters, base.getParameters()));{code}
to 
{code}base.setParameters(ConfigurationParameters.of(base.getParameters(), parameters));{code}

and thus actually doing what we intend to do: replace the existing entries in the {{SecurityConfiguration}} by the new ones.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)