[jira] [Comment Edited] (OAK-793) Authentication: Document changes wrt. Jackrabbit
[
https://issues.apache.org/jira/browse/OAK-793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13710893#comment-13710893
]
angela edited comment on OAK-793 at 7/30/13 7:49 AM:
-
h4. 1. Characteristics of the Default Implementation
h5. Null Login
As of Oak 1.0 Repository#login() and Repository#login(null, wspName) is no
longer
treated as guest login. This behavior of Jackrabbit-core is violating
the specification, which defines that null-login should be used for those cases
where the authentication process is handled outside of the repository (- see
pre-authentication below).
In order to get a full backwards compatible behavior OAK provides a specific
GuestLoginModule [0] that can be added to the JAAS (or corresponding OSGI)
configuration.
Example JAAS Configuration:
{code}
jackrabbit.oak {
org.apache.jackrabbit.oak.spi.security.authentication.GuestLoginModule
optional;
org.apache.jackrabbit.oak.security.authentication.user.LoginModuleImpl
required;
};
{code}
h5. Guest Login
With respect to guest login (aka anonymous login) the OAK content repository
out of the box contains the following modifications:
- null login != guest login
- no anonymous login with uid/pw
As explained in 1) the null login will not longer fall back to a guest login
unless explicitly configured (- GuestLoginModule).
The proper way to obtain an guest session as of OAK is as specified by JSR 283:
{code}
String wspName = null;
Session anonymous = repository.login(new GuestCredentials(), wspName);
{code}
Similarly, the special treatment that jackrabbit core applied for
the guest (anonymous) user has been omitted altogether in OAK. In the
default setup the anonymous user will created without any password. Therefore
explicitly uid/pw login using the anonymous userId will no longer work.
This behavior is now consistent with the default login of any other user
which doesn't have a password set.
h5. Pre-Authentication in the LoginContextProvider
Like in Jackrabbit-core the repository internal authentication verification can
be skipped by calling Repository#login() or Repository#login(null, wspName).
In this case the repository implementation expects the verification to be
performed prior to the login call.
This behavior is provided by the default implementation of the
LoginContextProvider [1]
which expects a Subject to be available with the current
java.security.AccessControlContext.
However, in contrast to Jackrabbit-core the current implementation does not
try to extend the pre-authenticated subject but skips the internal verification
step altogether.
Since the LoginContextProvider is a configurable with the authentication setup
OAK users also have the following options by providing a custom
LoginContextProvider:
- Disable pre-authentication by not trying to retrieve a pre-authenticated
Subject.
- Add support for extending the pre-authenticated Subject by always passing the
Subject to the JaasLoginContext
- Dropping JAAS altogether by providing a custom implementation of the
org.apache.jackrabbit.oak.spi.security.authentication.LoginContext [2]
interface.
Example how to use the pre-auth:
{code}
String userId = test;
/**
Retrive valid principals e.g. by calling jackrabbit API
- PrincipalManager#getPrincipal and/or #getGroupMembership
or from Oak SPI
- PrincipalProvider#getPrincipals(String userId)
*/
Set? extends Principal principals = getPrincipals(userId);
AuthInfo authInfo = new AuthInfoImpl(userId, Collections.String,
ObjectemptyMap(), principals);
Subject subject = new Subject(true, principals,
Collections.singleton(authInfo), Collections.ObjectemptySet());
Session session;
try {
session = Subject.doAsPrivileged(subject, new
PrivilegedExceptionActionSession() {
@Override
public Session run() throws Exception {
return login(null, null);
}
}, null);
} catch (PrivilegedActionException e) {
throw new RepositoryException(failed to retrieve session., e);
}
{code}
h4. 2. Impersonation
h5. Self-Impersonation (aka Cloning a Session)
As of OAK 1.0 the latest changes made to JSR 333 with respect to
Session#impersonate
have been adopted [3]: Any attempt to impersonate the same session
(self-impersonation)
will succeed as long as the user is still valid.
h5. Impersonation Credentials
The OAK implementation of Session#impersonate no longer uses SimpleCredentials
to
transport the original Subject but rather performs the login with dedicated
ImpersonationCredentials [4].
With this change the impersonation feature no longer relies on SimpleCredentials
being passed to Session#impersonate call. Instead the specified credentials are
passed to a new instance of ImpersonationCredentials delegating the evaluation
and
validation of the specified Credentials to the
[jira] [Commented] (OAK-803) Backwards compatibility of long-lived sessions
[
https://issues.apache.org/jira/browse/OAK-803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13723585#comment-13723585
]
Michael Dürig commented on OAK-803:
---
I created JCR-3634 to track adding a login method to {{JackrabbitRepository}}
that has a separate {{attributes}} parameter.
Backwards compatibility of long-lived sessions
--
Key: OAK-803
URL: https://issues.apache.org/jira/browse/OAK-803
Project: Jackrabbit Oak
Issue Type: Improvement
Components: jcr
Reporter: Jukka Zitting
Assignee: Michael Dürig
The auto-refresh mode added in OAK-88 should perhaps be enabled by default,
with warning logs to let clients know that relying on such a default behavior
without explicit per-session configuration might not be supported in a future
release.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (OAK-910) Privilege Management: Document changes wrt Jackrabbit
[
https://issues.apache.org/jira/browse/OAK-910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13720871#comment-13720871
]
angela edited comment on OAK-910 at 7/30/13 9:08 AM:
-
h4. 1. General Characteristics of the Privilege Management Implementation
As of OAK the built-in and custom privileges are stored in the repository
underneath /jcr:system/rep:privileges. Similar to other repository level date
(node types, namespaces and versions) this location is shared by all workspaces
present in the repository. The nodes and properties storing the privilege
definitions are protected by their node type definition. In addition a
specific privilege {{Validator}} and {{CommitHook}} implementations assert the
consistency of the privilege store. The built-in privileges are installed using
a dedicated implementation of the {{RepositoryInitializer}} [0].
h4. 2. Built-in Privilege Definitions
* All Privileges as defined by JSR 283
** jcr:read
** jcr:modifyProperties
** jcr:addChildNodes
** jcr:removeNode
** jcr:removeChildNodes
** jcr:readAccessControl
** jcr:modifyAccessControl
** jcr:lockManagement
** jcr:versionManagement
** jcr:nodeTypeManagement
** jcr:retentionManagement (NOTE: retention management not yet implemented)
** jcr:lifecycleManagement (NOTE: lifecycle management not yet implemented)
** jcr:write
** jcr:all
* All Privileges defined by JSR 333
** jcr:workspaceManagement (NOTE: wsp management not yet implemented)
** jcr:nodeTypeDefinitionManagement
** jcr:namespaceManagement
* All Privileges defined by Jackrabbit 2.x
** rep:write
** rep:privilegeManagement
* new privileges defined by OAK 1.0:
** rep:userManagement
** rep:readNodes
** rep:readProperties
** rep:addProperties
** rep:alterProperties
** rep:removeProperties
Note the following differences with respect to Jackrabbit 2.x definitions:
* jcr:read is now an aggregation of rep:readNodes and rep:readProperties
* jcr:modifyProperties is now an aggregation of rep:addProperties,
rep:alterProperties and rep:removeProperties
h4. 3. Node Type Definitions
The following privilege related built-in node types have been added in OAK 1.0.
They are used to represent built-in and custom privilege definitions in the
repository.
{code}
[rep:Privileges]
+ * (rep:Privilege) = rep:Privilege protected ABORT
- rep:next (LONG) protected multiple mandatory
[rep:Privilege]
- rep:isAbstract (BOOLEAN) protected
- rep:aggregates (NAME) protected multiple
- rep:bits (LONG) protected multiple mandatory
{code}
h4. 4. API Extensions
-
h4. 5. Configuration
* PrivilegeConfiguration [1]:
** getPrivilegeManager - returns a new instance of the PrivilegeManager
interface such as exposed by JackrabbitWorkspace#getPrivilegeManager. Note that
the default implementation is based on OAK API and can equally be used for
privilege related tasks in the OAK layer.
h4. 6. References
[0]
http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/security/privilege/PrivilegeInitializer.java
[1]
http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/security/privilege/PrivilegeConfiguration.java
was (Author: anchela):
h4. 1. General Characteristics of the Privilege Management Implementation
As of OAK the built-in and custom privileges are stored in the repository
underneath /jcr:system/rep:privileges. Similar to other repository level date
(node types, namespaces and versions) this location is shared by all workspaces
present in the repository. The nodes and properties storing the privilege
definitions are protected by their node type definition. In addition a
specific privilege validator asserts the consistency of the privilege store.
h4. 2. Built-in Privilege Definitions
* All Privileges as defined by JSR 283
** jcr:read
** jcr:modifyProperties
** jcr:addChildNodes
** jcr:removeNode
** jcr:removeChildNodes
** jcr:readAccessControl
** jcr:modifyAccessControl
** jcr:lockManagement
** jcr:versionManagement
** jcr:nodeTypeManagement
** jcr:retentionManagement (NOTE: retention management not yet implemented)
** jcr:lifecycleManagement (NOTE: lifecycle management not yet implemented)
** jcr:write
** jcr:all
* All Privileges defined by JSR 333
** jcr:workspaceManagement (NOTE: wsp management not yet implemented)
** jcr:nodeTypeDefinitionManagement
** jcr:namespaceManagement
* All Privileges defined by Jackrabbit 2.x
** rep:write
** rep:privilegeManagement
* new privileges defined by OAK 1.0:
** rep:userManagement
** rep:readNodes
** rep:readProperties
** rep:addProperties
** rep:alterProperties
** rep:removeProperties
Note the following differences with respect to Jackrabbit 2.x definitions:
* jcr:read is now an aggregation of rep:readNodes and rep:readProperties
* jcr:modifyProperties is now an aggregation of rep:addProperties,
[jira] [Comment Edited] (OAK-910) Privilege Management: Document changes wrt Jackrabbit
[
https://issues.apache.org/jira/browse/OAK-910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13720871#comment-13720871
]
angela edited comment on OAK-910 at 7/30/13 9:19 AM:
-
h4. 1. Characteristics of the Privilege Management Implementation
h5. General Notes
As of OAK the built-in and custom privileges are stored in the repository
underneath {{/jcr:system/rep:privileges}}. Similar to other repository level
date (node types, namespaces and versions) this location is shared by all
workspaces present in the repository. The nodes and properties storing the
privilege definitions are protected by their node type definition. In addition
a specific privilege {{Validator}} and {{CommitHook}} implementations assert
the consistency of the privilege store. The built-in privileges are installed
using a dedicated implementation of the {{RepositoryInitializer}} [0].
h5. Registration of Custom Privileges
As far as registration of custom privileges the OAK implementation behaves
different to Jackrabbit 2.x in the following aspects:
* Registration of new privileges fails with {{IllegalStateException}} if the
editing session has pending changes.
* Any validation is performed by CommitHooks in order to make sure that
modifications made on the OAK API directly is equally verified. Subsequently
any violation (permission, privilege consistency) is only detected at the end
of the registration process. The privilege manager itself does not perform any
validation.
h4. 2. Built-in Privilege Definitions
* All Privileges as defined by JSR 283
** jcr:read
** jcr:modifyProperties
** jcr:addChildNodes
** jcr:removeNode
** jcr:removeChildNodes
** jcr:readAccessControl
** jcr:modifyAccessControl
** jcr:lockManagement
** jcr:versionManagement
** jcr:nodeTypeManagement
** jcr:retentionManagement (NOTE: retention management not yet implemented)
** jcr:lifecycleManagement (NOTE: lifecycle management not yet implemented)
** jcr:write
** jcr:all
* All Privileges defined by JSR 333
** jcr:workspaceManagement (NOTE: wsp management not yet implemented)
** jcr:nodeTypeDefinitionManagement
** jcr:namespaceManagement
* All Privileges defined by Jackrabbit 2.x
** rep:write
** rep:privilegeManagement
* new privileges defined by OAK 1.0:
** rep:userManagement
** rep:readNodes
** rep:readProperties
** rep:addProperties
** rep:alterProperties
** rep:removeProperties
Note the following differences with respect to Jackrabbit 2.x definitions:
* jcr:read is now an aggregation of rep:readNodes and rep:readProperties
* jcr:modifyProperties is now an aggregation of rep:addProperties,
rep:alterProperties and rep:removeProperties
h4. 3. Node Type Definitions
The following privilege related built-in node types have been added in OAK 1.0.
They are used to represent built-in and custom privilege definitions in the
repository.
{code}
[rep:Privileges]
+ * (rep:Privilege) = rep:Privilege protected ABORT
- rep:next (LONG) protected multiple mandatory
[rep:Privilege]
- rep:isAbstract (BOOLEAN) protected
- rep:aggregates (NAME) protected multiple
- rep:bits (LONG) protected multiple mandatory
{code}
h4. 4. API Extensions
-
h4. 5. Configuration
* PrivilegeConfiguration [1]:
** getPrivilegeManager - returns a new instance of the PrivilegeManager
interface such as exposed by JackrabbitWorkspace#getPrivilegeManager. Note that
the default implementation is based on OAK API and can equally be used for
privilege related tasks in the OAK layer.
h4. 6. References
[0]
http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/security/privilege/PrivilegeInitializer.java
[1]
http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/security/privilege/PrivilegeConfiguration.java
was (Author: anchela):
h4. 1. General Characteristics of the Privilege Management Implementation
As of OAK the built-in and custom privileges are stored in the repository
underneath /jcr:system/rep:privileges. Similar to other repository level date
(node types, namespaces and versions) this location is shared by all workspaces
present in the repository. The nodes and properties storing the privilege
definitions are protected by their node type definition. In addition a
specific privilege {{Validator}} and {{CommitHook}} implementations assert the
consistency of the privilege store. The built-in privileges are installed using
a dedicated implementation of the {{RepositoryInitializer}} [0].
h4. 2. Built-in Privilege Definitions
* All Privileges as defined by JSR 283
** jcr:read
** jcr:modifyProperties
** jcr:addChildNodes
** jcr:removeNode
** jcr:removeChildNodes
** jcr:readAccessControl
** jcr:modifyAccessControl
** jcr:lockManagement
** jcr:versionManagement
** jcr:nodeTypeManagement
** jcr:retentionManagement (NOTE: retention
[jira] [Comment Edited] (OAK-910) Privilege Management: Document changes wrt Jackrabbit
[
https://issues.apache.org/jira/browse/OAK-910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13720871#comment-13720871
]
angela edited comment on OAK-910 at 7/30/13 9:20 AM:
-
h4. 1. Characteristics of the Privilege Management Implementation
h5. General Notes
As of OAK the built-in and custom privileges are stored in the repository
underneath {{/jcr:system/rep:privileges}}. Similar to other repository level
date (node types, namespaces and versions) this location is shared by all
workspaces present in the repository. The nodes and properties storing the
privilege definitions are protected by their node type definition. In addition
a specific privilege {{Validator}} and {{CommitHook}} implementations assert
the consistency of the privilege store. The built-in privileges are installed
using a dedicated implementation of the {{RepositoryInitializer}} [0].
h5. Registration of Custom Privileges
As far as registration of custom privileges the OAK implementation behaves
different to Jackrabbit 2.x in the following aspects:
* Registration of new privileges fails with {{IllegalStateException}} if the
editing session has pending changes.
* Any validation is performed by CommitHooks in order to make sure that
modifications made on the OAK API directly is equally verified. Subsequently
any violation (permission, privilege consistency) is only detected at the end
of the registration process. The privilege manager itself does not perform any
validation.
h4. 2. Built-in Privilege Definitions
* All Privileges as defined by JSR 283
** jcr:read
** jcr:modifyProperties
** jcr:addChildNodes
** jcr:removeNode
** jcr:removeChildNodes
** jcr:readAccessControl
** jcr:modifyAccessControl
** jcr:lockManagement
** jcr:versionManagement
** jcr:nodeTypeManagement
** jcr:retentionManagement (NOTE: retention management not yet implemented)
** jcr:lifecycleManagement (NOTE: lifecycle management not yet implemented)
** jcr:write
** jcr:all
* All Privileges defined by JSR 333
** jcr:workspaceManagement (NOTE: wsp management not yet implemented)
** jcr:nodeTypeDefinitionManagement
** jcr:namespaceManagement
* All Privileges defined by Jackrabbit 2.x
** rep:write
** rep:privilegeManagement
* new privileges defined by OAK 1.0:
** rep:userManagement
** rep:readNodes
** rep:readProperties
** rep:addProperties
** rep:alterProperties
** rep:removeProperties
Note the following differences with respect to Jackrabbit 2.x definitions:
* jcr:read is now an aggregation of rep:readNodes and rep:readProperties
* jcr:modifyProperties is now an aggregation of rep:addProperties,
rep:alterProperties and rep:removeProperties
h4. 3. Node Type Definitions
The following privilege related built-in node types have been added in OAK 1.0.
They are used to represent built-in and custom privilege definitions in the
repository.
{code}
[rep:Privileges]
+ * (rep:Privilege) = rep:Privilege protected ABORT
- rep:next (LONG) protected multiple mandatory
[rep:Privilege]
- rep:isAbstract (BOOLEAN) protected
- rep:aggregates (NAME) protected multiple
- rep:bits (LONG) protected multiple mandatory
{code}
h4. 4. API Extensions
-
h4. 5. Configuration
* {{PrivilegeConfiguration}} [1]:
** {{getPrivilegeManager}} - returns a new instance of the
{{PrivilegeManager}} interface such as exposed by
{{JackrabbitWorkspace#getPrivilegeManager}}. Note that the default
implementation is based on OAK API and can equally be used for privilege
related tasks in the OAK layer.
h4. 6. References
[0]
http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/security/privilege/PrivilegeInitializer.java
[1]
http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/security/privilege/PrivilegeConfiguration.java
was (Author: anchela):
h4. 1. Characteristics of the Privilege Management Implementation
h5. General Notes
As of OAK the built-in and custom privileges are stored in the repository
underneath {{/jcr:system/rep:privileges}}. Similar to other repository level
date (node types, namespaces and versions) this location is shared by all
workspaces present in the repository. The nodes and properties storing the
privilege definitions are protected by their node type definition. In addition
a specific privilege {{Validator}} and {{CommitHook}} implementations assert
the consistency of the privilege store. The built-in privileges are installed
using a dedicated implementation of the {{RepositoryInitializer}} [0].
h5. Registration of Custom Privileges
As far as registration of custom privileges the OAK implementation behaves
different to Jackrabbit 2.x in the following aspects:
* Registration of new privileges fails with {{IllegalStateException}} if the
editing session has pending changes.
* Any validation is performed by
[jira] [Comment Edited] (OAK-793) Authentication: Document changes wrt. Jackrabbit
[
https://issues.apache.org/jira/browse/OAK-793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13710893#comment-13710893
]
angela edited comment on OAK-793 at 7/30/13 9:29 AM:
-
h4. 1. Characteristics of the Default Implementation
h5. Null Login
As of Oak 1.0 {{Repository#login()}} and {{Repository#login(null, wspName)}} is
no longer treated as guest login. This behavior of Jackrabbit-core is violating
the specification, which defines that null-login should be used for those cases
where the authentication process is handled outside of the repository (- see
pre-authentication below).
In order to get a full backwards compatible behavior OAK provides a specific
{{GuestLoginModule}} [0] that can be added to the JAAS (or corresponding OSGI)
configuration.
Example JAAS Configuration:
{code}
jackrabbit.oak {
org.apache.jackrabbit.oak.spi.security.authentication.GuestLoginModule
optional;
org.apache.jackrabbit.oak.security.authentication.user.LoginModuleImpl
required;
};
{code}
h5. Guest Login
With respect to guest login (aka anonymous login) the OAK content repository
out of the box contains the following modifications:
- null login != guest login
- no anonymous login with uid/pw
As explained in 1) the null login will not longer fall back to a guest login
unless explicitly configured (- {{GuestLoginModule}}).
The proper way to obtain an guest session as of OAK is as specified by JSR 283:
{code}
String wspName = null;
Session anonymous = repository.login(new GuestCredentials(), wspName);
{code}
Similarly, the special treatment that jackrabbit core applied for
the guest (anonymous) user has been omitted altogether in OAK. In the
default setup the anonymous user will created without any password. Therefore
explicitly uid/pw login using the anonymous userId will no longer work.
This behavior is now consistent with the default login of any other user
which doesn't have a password set.
h5. Pre-Authentication in the LoginContextProvider
Like in Jackrabbit-core the repository internal authentication verification can
be skipped by calling {{Repository#login()}} or {{Repository#login(null,
wspName)}}. In this case the repository implementation expects the verification
to be performed prior to the login call.
This behavior is provided by the default implementation of the
{{LoginContextProvider}} [1] which expects a {{Subject}} to be available with
the current {{java.security.AccessControlContext}}. However, in contrast to
Jackrabbit-core the current implementation does not try to extend the
pre-authenticated subject but skips the internal verification step altogether.
Since the {{LoginContextProvider}} is a configurable with the authentication
setup OAK users also have the following options by providing a custom
{{LoginContextProvider}}:
- Disable pre-authentication by not trying to retrieve a pre-authenticated
{{Subject}}.
- Add support for extending the pre-authenticated subject by always passing
writable subjects to the {{JaasLoginContext}}
- Dropping JAAS altogether by providing a custom implementation of the
{{org.apache.jackrabbit.oak.spi.security.authentication.LoginContext}} [2]
interface.
Example how to use the pre-auth:
{code}
String userId = test;
/**
Retrive valid principals e.g. by calling jackrabbit API
- PrincipalManager#getPrincipal and/or #getGroupMembership
or from Oak SPI
- PrincipalProvider#getPrincipals(String userId)
*/
Set? extends Principal principals = getPrincipals(userId);
AuthInfo authInfo = new AuthInfoImpl(userId, Collections.String,
ObjectemptyMap(), principals);
Subject subject = new Subject(true, principals,
Collections.singleton(authInfo), Collections.ObjectemptySet());
Session session;
try {
session = Subject.doAsPrivileged(subject, new
PrivilegedExceptionActionSession() {
@Override
public Session run() throws Exception {
return login(null, null);
}
}, null);
} catch (PrivilegedActionException e) {
throw new RepositoryException(failed to retrieve session., e);
}
{code}
h4. 2. Impersonation
h5. Self-Impersonation (aka Cloning a Session)
As of OAK 1.0 the latest changes made to JSR 333 with respect to
{{Session#impersonate}} have been adopted [3]: Any attempt to impersonate the
same session (self-impersonation) will succeed as long as the user is still
valid.
h5. Impersonation Credentials
The OAK implementation of {{Session#impersonate}} no longer uses
{{SimpleCredentials}} to transport the original {{Subject}} but rather performs
the login with dedicated {{ImpersonationCredentials}} [4].
With this change the impersonation feature no longer relies on
{{SimpleCredentials}} being passed to {{Session#impersonate}} call. Instead the
specified credentials are passed to a new instance of
[jira] [Resolved] (OAK-755) Remove privilege mgt configuration from SecurityProvider
[ https://issues.apache.org/jira/browse/OAK-755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela resolved OAK-755. Resolution: Won't Fix Revision 1508359: slightly adjusted the securityconfiguration such that the privilege related part doesn't require special handling. - resolving wontfix. Remove privilege mgt configuration from SecurityProvider Key: OAK-755 URL: https://issues.apache.org/jira/browse/OAK-755 Project: Jackrabbit Oak Issue Type: Sub-task Components: core Reporter: angela in contrast to the pluggable features listed in the container issue the privilege mgt should be considered built-in and global functionality of the repository similar to node types, namespaces and versioning. IMO it doesn't make sense to provide extra plugability for that part of the security setup. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OAK-770) NodeImpl doesn't implement JackrabbitNode
[ https://issues.apache.org/jira/browse/OAK-770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13723650#comment-13723650 ] angela commented on OAK-770: Revision 1508367: added dummy implementation that throws UnsupportRepositoryOperationException including issue reference in the exception message. NodeImpl doesn't implement JackrabbitNode - Key: OAK-770 URL: https://issues.apache.org/jira/browse/OAK-770 Project: Jackrabbit Oak Issue Type: Bug Components: jcr Reporter: angela Priority: Minor for backwards compatibility it would be desirable if NodeImpl would implement the 2 methods defined on JackrabbitNode: - void rename(java.lang.String) - void setMixins(java.lang.String[]) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OAK-770) NodeImpl should implement JackrabbitNode
[ https://issues.apache.org/jira/browse/OAK-770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated OAK-770: --- Summary: NodeImpl should implement JackrabbitNode (was: NodeImpl doesn't implement JackrabbitNode) NodeImpl should implement JackrabbitNode Key: OAK-770 URL: https://issues.apache.org/jira/browse/OAK-770 Project: Jackrabbit Oak Issue Type: Bug Components: jcr Reporter: angela Priority: Minor for backwards compatibility it would be desirable if NodeImpl would implement the 2 methods defined on JackrabbitNode: - void rename(java.lang.String) - void setMixins(java.lang.String[]) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (OAK-910) Privilege Management: Document changes wrt Jackrabbit
[
https://issues.apache.org/jira/browse/OAK-910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13720871#comment-13720871
]
angela edited comment on OAK-910 at 7/30/13 10:02 AM:
--
h4. 1. Characteristics of the Privilege Management Implementation
h5. General Notes
As of OAK the built-in and custom privileges are stored in the repository
underneath {{/jcr:system/rep:privileges}}. Similar to other repository level
date (node types, namespaces and versions) this location is shared by all
workspaces present in the repository. The nodes and properties storing the
privilege definitions are protected by their node type definition. In addition
a specific privilege {{Validator}} and {{CommitHook}} implementations assert
the consistency of the privilege store. The built-in privileges are installed
using a dedicated implementation of the {{RepositoryInitializer}} [0].
h5. Registration of Custom Privileges
As far as registration of custom privileges the OAK implementation behaves
different to Jackrabbit 2.x in the following aspects:
* Registration of new privileges fails with {{IllegalStateException}} if the
editing session has pending changes.
* Any validation is performed by CommitHooks in order to make sure that
modifications made on the OAK API directly is equally verified. Subsequently
any violation (permission, privilege consistency) is only detected at the end
of the registration process. The privilege manager itself does not perform any
validation.
h4. 2. Built-in Privilege Definitions
* All Privileges as defined by JSR 283
** jcr:read
** jcr:modifyProperties
** jcr:addChildNodes
** jcr:removeNode
** jcr:removeChildNodes
** jcr:readAccessControl
** jcr:modifyAccessControl
** jcr:lockManagement
** jcr:versionManagement
** jcr:nodeTypeManagement
** jcr:retentionManagement (NOTE: retention management not yet implemented)
** jcr:lifecycleManagement (NOTE: lifecycle management not yet implemented)
** jcr:write
** jcr:all
* All Privileges defined by JSR 333
** jcr:workspaceManagement (NOTE: wsp management not yet implemented)
** jcr:nodeTypeDefinitionManagement
** jcr:namespaceManagement
* All Privileges defined by Jackrabbit 2.x
** rep:write
** rep:privilegeManagement
* New Privileges defined by OAK 1.0:
** rep:userManagement
** rep:readNodes
** rep:readProperties
** rep:addProperties
** rep:alterProperties
** rep:removeProperties
Note the following differences with respect to Jackrabbit 2.x definitions:
* jcr:read is now an aggregation of rep:readNodes and rep:readProperties
* jcr:modifyProperties is now an aggregation of rep:addProperties,
rep:alterProperties and rep:removeProperties
h4. 3. Node Type Definitions
The following privilege related built-in node types have been added in OAK 1.0.
They are used to represent built-in and custom privilege definitions in the
repository.
{code}
[rep:Privileges]
+ * (rep:Privilege) = rep:Privilege protected ABORT
- rep:next (LONG) protected multiple mandatory
[rep:Privilege]
- rep:isAbstract (BOOLEAN) protected
- rep:aggregates (NAME) protected multiple
- rep:bits (LONG) protected multiple mandatory
{code}
h4. 4. API Extensions
-
h4. 5. Configuration
* {{PrivilegeConfiguration}} [1]:
** {{getPrivilegeManager}} - returns a new instance of the
{{PrivilegeManager}} interface such as exposed by
{{JackrabbitWorkspace#getPrivilegeManager}}. Note that the default
implementation is based on OAK API and can equally be used for privilege
related tasks in the OAK layer.
h4. 6. References
[0]
http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/security/privilege/PrivilegeInitializer.java
[1]
http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/security/privilege/PrivilegeConfiguration.java
was (Author: anchela):
h4. 1. Characteristics of the Privilege Management Implementation
h5. General Notes
As of OAK the built-in and custom privileges are stored in the repository
underneath {{/jcr:system/rep:privileges}}. Similar to other repository level
date (node types, namespaces and versions) this location is shared by all
workspaces present in the repository. The nodes and properties storing the
privilege definitions are protected by their node type definition. In addition
a specific privilege {{Validator}} and {{CommitHook}} implementations assert
the consistency of the privilege store. The built-in privileges are installed
using a dedicated implementation of the {{RepositoryInitializer}} [0].
h5. Registration of Custom Privileges
As far as registration of custom privileges the OAK implementation behaves
different to Jackrabbit 2.x in the following aspects:
* Registration of new privileges fails with {{IllegalStateException}} if the
editing session has pending changes.
* Any validation is performed by
[jira] [Created] (OAK-934) NodeIterator.getSize() can return Long.MAX_VALUE for the MongoMK
Thomas Mueller created OAK-934: -- Summary: NodeIterator.getSize() can return Long.MAX_VALUE for the MongoMK Key: OAK-934 URL: https://issues.apache.org/jira/browse/OAK-934 Project: Jackrabbit Oak Issue Type: Bug Components: core, jcr, mongomk Reporter: Thomas Mueller Assignee: Thomas Mueller When using the MongoMK, the method NodeIterator.getSize() returns Long.MAX_VALUE if there are many child nodes (more than MongoMK.MANY_CHILDREN_THRESHOLD). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OAK-935) Implement JackrabbitRepository
Michael Dürig created OAK-935:
-
Summary: Implement JackrabbitRepository
Key: OAK-935
URL: https://issues.apache.org/jira/browse/OAK-935
Project: Jackrabbit Oak
Issue Type: New Feature
Components: jcr
Reporter: Michael Dürig
To profit from the changes from JCR-3634 and for backward compatibility Oak
should implement {{JackrabbitRepository}}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OAK-935) Implement JackrabbitRepository
[
https://issues.apache.org/jira/browse/OAK-935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig updated OAK-935:
--
Assignee: Michael Dürig
Implement JackrabbitRepository
--
Key: OAK-935
URL: https://issues.apache.org/jira/browse/OAK-935
Project: Jackrabbit Oak
Issue Type: New Feature
Components: jcr
Reporter: Michael Dürig
Assignee: Michael Dürig
To profit from the changes from JCR-3634 and for backward compatibility Oak
should implement {{JackrabbitRepository}}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (OAK-792) AccessControl Management and Permissions: Document changes wrt. Jackrabbit
[ https://issues.apache.org/jira/browse/OAK-792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13718362#comment-13718362 ] angela edited comment on OAK-792 at 7/30/13 3:41 PM: - h4. 1. Characteristics of the Default Implementation h5. JCR API h6. Session#hasPermission and #checkPermission h6. AccessControlManager#hasPrivilege and #getPrivileges h6. AccessControlManager#getEffectivePolicies h5. Jackrabbit API h6. Principal-based Access Control h5. Mapping of JCR Actions to Permissions h5. Permission Evaluation h6. Reading h6. Property Modification h6. Node Removal h6. Version Management h6. User Management h4. 2. API Extensions h4. 3. Configuration h4. 4 References was (Author: anchela): 1) Characteristics of the Default Implementation 2) API Extensions 3) Configuration 4) References AccessControl Management and Permissions: Document changes wrt. Jackrabbit -- Key: OAK-792 URL: https://issues.apache.org/jira/browse/OAK-792 Project: Jackrabbit Oak Issue Type: Sub-task Components: jcr Reporter: angela Assignee: angela -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
