[
https://issues.apache.org/jira/browse/OAK-1476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated OAK-1476:
---------------------------------
Attachment: OAK-1476.patch
Patch to fix the issue.
To remove the hardcoded SecurityConfiguration in activator I need to refactor
the SecurityProvider. The way configuration is currently managed is very
fragile in OSGi env. Instead the patch takes following approach
# By default all dependent configuration in SecurityProvider are marked as
otpional unary (or option multiple where required)
# All the SecurityConfiguration components are now marked with
ConfigurationPolicy to REQUIRED. So they would not be created unless specific
configuration is provided for them
# If user does not want to change the default config the SecurityProvider would
get activated with defaults and would be then used by required components
# if user wants to change some configuration then they need to follow steps
under customizing config
*Customizing Config*
A) Create a configuration for Securityprovider with pid
{{org.apache.jackrabbit.oak.security.SecurityProvider}} and following content
{noformat}
authorizationConfiguration.cardinality.minimum=1
userConfiguration.cardinality.minimum=1
{noformat}
In above case we are changing the default configuration for
{{authorizationConfiguration}} and {{userConfiguration}}. Here we utilize the
new feature added in Declarative Service (FELIX-4391) where a user can change
the cardinality of the reference via configuration. In simple words through
above config we change the requirement of {{userConfiguration}} for
SecurityProviderImpl from optional to mandatory. So untill
{{UserConfiguration}} service is not found SecurityProviderImpl would not be
activated
B) As second step user needs to create required config for components which it
want to change. So here it must create config for
{{org.apache.jackrabbit.oak.security.user.UserConfigurationImpl.config}}
{noformat}
groupsPath="/home/groups"
usersPath="/home/users"
defaultDepth="1"
importBehavior="besteffort"
{noformat}
Above setup ensures that SecurityProvider gets activated only after all default
and overridden config are determined. And repository gets configured with a
stable configuration
*Changes done*
* Removed the Activator from JCR and instead added a SCR based
OakRepositoryFactory which does the job of registering the Repository service
* Change the configuration policy for various security related configuration to
REQUIRED (see above).
* Change the references in SecurityProvider to optional multiple (see above)
With this change the problem referred at [1] is also fixed and my testcase
passes.
[1] http://markmail.org/thread/4lxpapeba3bk3d3k
> Hardcoded SecurityProvider implementation in oak-jcr Activator
> --------------------------------------------------------------
>
> Key: OAK-1476
> URL: https://issues.apache.org/jira/browse/OAK-1476
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr
> Reporter: angela
> Assignee: Chetan Mehrotra
> Fix For: 0.20
>
> Attachments: OAK-1476.patch
>
>
> the Activator in o.a.j.oak.jcr.jcr.osgi contains a hardcoded reference to the
> SecurityProviderImpl. This is obviously not the desired outcome of making the
> security part pluggable at runtime.
> [~jukkaz], since you are the author of the Activator, could you take a look
> at this again?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
