[jira] [Commented] (JCR-4050) Allow creation of users with existing password hashes in UserManager
[ https://issues.apache.org/jira/browse/JCR-4050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15878456#comment-15878456 ] Jeffrey Bornemann commented on JCR-4050: Hey [~anchela], I actually see your point here, and agree. We have a bit of an edge case scenario here. Thanks for your comments. > Allow creation of users with existing password hashes in UserManager > - > > Key: JCR-4050 > URL: https://issues.apache.org/jira/browse/JCR-4050 > Project: Jackrabbit Content Repository > Issue Type: New Feature > Components: jackrabbit-api, jackrabbit-core, security >Reporter: Jeffrey Bornemann >Priority: Minor > > We utilize the UserManager API within Grabbit for syncing authorizable nodes > between servers. > Unfortunately, when it comes to syncing users, and specifically setting > passwords from existing users; we have no public API facing way to create > users with existing password hashes. We currently have to resort to using > reflection, grabbing internal tree objects, and a bunch of nastiness that we > would love to avoid with this change. > Other consumers may also find this useful. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (JCR-4050) Allow creation of users with existing password hashes in UserManager
[ https://issues.apache.org/jira/browse/JCR-4050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15693929#comment-15693929 ] angela commented on JCR-4050: - [~bornemannjs], i see your point. on the other hand, the creation of the pw-hash should be consideren an implementation detail of a given user management implementation and i don't see too much benefit of having such an API call without the ability to generate the hash. in other words: a caller of that API would only be able to create a pw-hash by relying on implementation details, which IMO is looking for troubles. but since you are mentioning AEM Package Manager: is this related to Jackrabbit FileVault project? afaik that project within the Jackrabbit family provides means to package and install repository content including users. If that was anyhow related, I would recommend to provide patches there if you find room for improvement in terms of performance and scalability. > Allow creation of users with existing password hashes in UserManager > - > > Key: JCR-4050 > URL: https://issues.apache.org/jira/browse/JCR-4050 > Project: Jackrabbit Content Repository > Issue Type: New Feature > Components: jackrabbit-api, jackrabbit-core, security >Reporter: Jeffrey Bornemann >Priority: Minor > > We utilize the UserManager API within Grabbit for syncing authorizable nodes > between servers. > Unfortunately, when it comes to syncing users, and specifically setting > passwords from existing users; we have no public API facing way to create > users with existing password hashes. We currently have to resort to using > reflection, grabbing internal tree objects, and a bunch of nastiness that we > would love to avoid with this change. > Other consumers may also find this useful. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCR-4050) Allow creation of users with existing password hashes in UserManager
[ https://issues.apache.org/jira/browse/JCR-4050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15693911#comment-15693911 ] angela commented on JCR-4050: - [~olli], i have to say that i am pretty surprised to see the repo-init tool to allow for creation of regular users. i distinctly remember the initial idea was to provide a tool to create service users and that me and other security engineers strongly suggested to not expand that to regular users. i am not sure I understand what would be the use case for creating regular users during the repo init. and apart from that, if users were to be pre-created based on a configuration that can be share by different installations, i would strongly recommend to create them without password. writing the pw to the provision model really sounds like a very bad idea. /cc [~bdelacretaz] > Allow creation of users with existing password hashes in UserManager > - > > Key: JCR-4050 > URL: https://issues.apache.org/jira/browse/JCR-4050 > Project: Jackrabbit Content Repository > Issue Type: New Feature > Components: jackrabbit-api, jackrabbit-core, security >Reporter: Jeffrey Bornemann >Priority: Minor > > We utilize the UserManager API within Grabbit for syncing authorizable nodes > between servers. > Unfortunately, when it comes to syncing users, and specifically setting > passwords from existing users; we have no public API facing way to create > users with existing password hashes. We currently have to resort to using > reflection, grabbing internal tree objects, and a bunch of nastiness that we > would love to avoid with this change. > Other consumers may also find this useful. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCR-4050) Allow creation of users with existing password hashes in UserManager
[ https://issues.apache.org/jira/browse/JCR-4050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15635685#comment-15635685 ] Jeffrey Bornemann commented on JCR-4050: Thanks for your response! I'm not sure we explored JCR-remoting. At the time Grabbit was conceived, I know we explored vlt, and recap. We were using the AEM Package Manager at the time, and were looking for scalable, less time-consuming options. Since then, we have implemented other ways within Grabbit to improve performance beyond number of handshakes, such as compression, batch processing, delta syncing, etc. We have had some pretty decent community involvement, and contribution since then. Some of our users report syncing to 100+ nodes at a time effectively, and within reasonable time. We might have to take a look at the improvements you mentioned to see if we can draw any inspiration. I'm certainly happy to explore options, but I suspect anything that is a major deviation from the tools current approach is probably not a good trade from our current working, but less than ideal interaction with jackrabbit-api. rep:password is really the only "black sheep" we have had to poke at in the UserManager API to get it to behave the way we need it to. > Allow creation of users with existing password hashes in UserManager > - > > Key: JCR-4050 > URL: https://issues.apache.org/jira/browse/JCR-4050 > Project: Jackrabbit Content Repository > Issue Type: New Feature > Components: jackrabbit-api, jackrabbit-core, security >Reporter: Jeffrey Bornemann >Priority: Minor > > We utilize the UserManager API within Grabbit for syncing authorizable nodes > between servers. > Unfortunately, when it comes to syncing users, and specifically setting > passwords from existing users; we have no public API facing way to create > users with existing password hashes. We currently have to resort to using > reflection, grabbing internal tree objects, and a bunch of nastiness that we > would love to avoid with this change. > Other consumers may also find this useful. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCR-4050) Allow creation of users with existing password hashes in UserManager
[
https://issues.apache.org/jira/browse/JCR-4050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15633615#comment-15633615
]
Oliver Lietz commented on JCR-4050:
---
[~anchela], allowing password hashes with {{UserManager}} is very welcome. See
SLING-6219, otherwise we will see plain text passwords in provisioning model.
> Allow creation of users with existing password hashes in UserManager
> -
>
> Key: JCR-4050
> URL: https://issues.apache.org/jira/browse/JCR-4050
> Project: Jackrabbit Content Repository
> Issue Type: New Feature
> Components: jackrabbit-api, jackrabbit-core, security
>Reporter: Jeffrey Bornemann
>Priority: Minor
>
> We utilize the UserManager API within Grabbit for syncing authorizable nodes
> between servers.
> Unfortunately, when it comes to syncing users, and specifically setting
> passwords from existing users; we have no public API facing way to create
> users with existing password hashes. We currently have to resort to using
> reflection, grabbing internal tree objects, and a bunch of nastiness that we
> would love to avoid with this change.
> Other consumers may also find this useful.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCR-4050) Allow creation of users with existing password hashes in UserManager
[ https://issues.apache.org/jira/browse/JCR-4050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15633074#comment-15633074 ] angela commented on JCR-4050: - [~bornemannjs], thanks for the insights. on the documentation you state that you were evaluating different ways of synchronizing repository content between different instances and that WebDAV was not found to be efficient. Did you also evaluate the JCR-remoting with it's extension that allows to process large chunks of content with a single request? It has been improved recently by [~alfu] allowing to transport protected content (access control content to be precise) in a way that would allow to easily expand that to other protected items such as those stored with user/group content. While I see the point of your extension, my gut feeling tells me that this doesn't belong to the API contract... trying to explore other possibilities that would allow you to efficiently synchronizing your data. > Allow creation of users with existing password hashes in UserManager > - > > Key: JCR-4050 > URL: https://issues.apache.org/jira/browse/JCR-4050 > Project: Jackrabbit Content Repository > Issue Type: New Feature > Components: jackrabbit-api, jackrabbit-core, security >Reporter: Jeffrey Bornemann >Priority: Minor > > We utilize the UserManager API within Grabbit for syncing authorizable nodes > between servers. > Unfortunately, when it comes to syncing users, and specifically setting > passwords from existing users; we have no public API facing way to create > users with existing password hashes. We currently have to resort to using > reflection, grabbing internal tree objects, and a bunch of nastiness that we > would love to avoid with this change. > Other consumers may also find this useful. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCR-4050) Allow creation of users with existing password hashes in UserManager
[ https://issues.apache.org/jira/browse/JCR-4050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15633079#comment-15633079 ] angela commented on JCR-4050: - and btw: the workspace.xml excerpt above only applies to jackrabbit core; in oak it's an OSGi configuration. And since you are mentioning AEM: the user-xml-import is enabled in AEM by default, both with Jackrabbit and Oak > Allow creation of users with existing password hashes in UserManager > - > > Key: JCR-4050 > URL: https://issues.apache.org/jira/browse/JCR-4050 > Project: Jackrabbit Content Repository > Issue Type: New Feature > Components: jackrabbit-api, jackrabbit-core, security >Reporter: Jeffrey Bornemann >Priority: Minor > > We utilize the UserManager API within Grabbit for syncing authorizable nodes > between servers. > Unfortunately, when it comes to syncing users, and specifically setting > passwords from existing users; we have no public API facing way to create > users with existing password hashes. We currently have to resort to using > reflection, grabbing internal tree objects, and a bunch of nastiness that we > would love to avoid with this change. > Other consumers may also find this useful. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCR-4050) Allow creation of users with existing password hashes
[ https://issues.apache.org/jira/browse/JCR-4050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15628189#comment-15628189 ] Jeffrey Bornemann commented on JCR-4050: Hey [~anchela]! Thanks for the good information! I appreciate the prompt reply! Unfortunately, I don't think this approach will help us much in our circumstance for a few reasons. - Part of our model for syncing nodes in an efficient fashion is to create a continuous binary stream of repository data based on a custom encoding we have built from Google's protocol buffers, as opposed to XML. Sending, or building XML from data would be a bit of an approach departure for this corner case. Really we have only had to wrangle a bit with rep:password; Other protected properties we get by just fine by using UserManager, and the like. - Our users work with Jackrabbit through AEM, which does not have an elegant way of working with workspace.xml (I believe there are limited configuration options, as exposed from Felix); even furthermore, it's not something we would want to ask our users to do as a prerequisite for synching authorizables. We would love to keep it as plug-n-play as possible. I feel my patch https://github.com/apache/jackrabbit/pull/45 offers limited risk, and technical encumbrance; but I certainly will understand if you feel the change is redundant. Thanks again for the reply! > Allow creation of users with existing password hashes > -- > > Key: JCR-4050 > URL: https://issues.apache.org/jira/browse/JCR-4050 > Project: Jackrabbit Content Repository > Issue Type: New Feature > Components: jackrabbit-api, jackrabbit-core, security >Reporter: Jeffrey Bornemann >Priority: Minor > > We utilize the UserManager API within Grabbit for syncing authorizable nodes > between servers. > Unfortunately, when it comes to syncing users, and specifically setting > passwords from existing users; we have no public API facing way to create > users with existing password hashes. We currently have to resort to using > reflection, grabbing internal tree objects, and a bunch of nastiness that we > would love to avoid with this change. > Other consumers may also find this useful. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCR-4050) Allow creation of users with existing password hashes
[
https://issues.apache.org/jira/browse/JCR-4050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15621540#comment-15621540
]
angela commented on JCR-4050:
-
There exists in fact a way to create users with existing password hashes and
which is actually intended for synchronizing content between repositories: the
JCR xml import. If import of the protected user properties is properly enabled
this would exactly do, what you were looking for. Since the Xml import by
default ignores protected JCR nodes/properties, we defined plugins for both
Jackrabbit Core and Oak that provides that missing functionality.
For Oak it's documented at
http://jackrabbit.apache.org/oak/docs/security/user/default.html#XML_Import
For Jackrabbit Core there exists no official documentation but the mechanism is
the same: configure the protected item imports you wish to be active in the
workspace.xml of your target workspace. For example something like this:
{code}
[...]
{code}
Hope that helps
> Allow creation of users with existing password hashes
> --
>
> Key: JCR-4050
> URL: https://issues.apache.org/jira/browse/JCR-4050
> Project: Jackrabbit Content Repository
> Issue Type: New Feature
> Components: jackrabbit-api, jackrabbit-core, security
>Reporter: Jeffrey Bornemann
>Priority: Minor
>
> We utilize the UserManager API within Grabbit for syncing authorizable nodes
> between servers.
> Unfortunately, when it comes to syncing users, and specifically setting
> passwords from existing users; we have no public API facing way to create
> users with existing password hashes. We currently have to resort to using
> reflection, grabbing internal tree objects, and a bunch of nastiness that we
> would love to avoid with this change.
> Other consumers may also find this useful.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
