Re: Problems Implementing a Custom AccessManager
Hi. Thanks for the answers. Is there any date scheduled for the upgrade to Jackrabbit 1.5? ACL was what I was thinking to use, so maybe the upgrade resolves my problem (although I haven't been able to find much documentation on ACL in 1.5 (if someone knows where I can find it I'll appreciate the indication). What worries me the most is that if ACL in 1.5 is not suitable enough for my app, what would be the way to go? On Wed, Dec 17, 2008 at 1:34 AM, Torgeir Veimo torg...@pobox.com wrote: On 17 Dec 2008, at 03:59, Rory Douglas wrote: As for the AccessManager, I think there are plans to upgrade Sling to Jackrabbit 1.5, so it may be more worthwhile to wait for that use the repository-ACL-based AccessManager that comes with 1.5 rather than implementing your own. Or ping me I can send you what I cobbled together for ACL-based control. ACLs are not suitable for most web applications. They're declarative, while most interactive web applications require implicit or application specific security constraints. Sling really needs to allow custom AccessManager implementations. -- Torgeir Veimo torg...@pobox.com
Re: Problems Implementing a Custom AccessManager
Hi Felix. I tested what you told me, but I've seen it's not going to be possible only exporting org.apache.jackrabbit.core.security due to the fact that the AccessManager interface uses org.apache.jackrabbit.core.ItemId (so it will also need org.apache.jackrabbit.core exported, that by what you said I see is not an option). On the other hand I've had a look over the JSR-283 spec and the Jackrabbit 1.5 source code and it looks that it will include exactly what I need, so I think my best option is to hold on until you finish the migration. The thing is that I'm in a bit of a hurry with this part of my application, I've got my deadline quite near, so I hope you don't mind me daring to ask you how much time you estimate it will take (just to know if I can wait, or if I must implement this in some quickdirty way and expect an upgrade in the future). Thanks a lot for your help, and I hope you can help me out with this last doubt. Br, SebatiAn Gomez ;) On Wed, Dec 17, 2008 at 2:44 PM, Felix Meschberger fmesc...@gmail.comwrote: Hi Sebastien, Sebastian Gomez schrieb: Hi. Thanks for the answers. Is there any date scheduled for the upgrade to Jackrabbit 1.5? ACL was what I was thinking to use, so maybe the upgrade resolves my problem (although I haven't been able to find much documentation on ACL in 1.5 (if someone knows where I can find it I'll appreciate the indication). What worries me the most is that if ACL in 1.5 is not suitable enough for my app, what would be the way to go? As Alex said, I am already working on migrating Sling's Jackrabbit inclusion to 1.5. Now for documentation: There is the jackrabbit.apache.org site and there is a Jackrabbit Wiki. If you don't find any documentation there, it is probably best to just ask on the Jackrabbit dev or user list. Finally, since the Jackrabbit access control functionality is an implementation of the JSR-283 (JCR 2.0) access control functionality, you might find the appropriate description there. The public review draft is available from http://www.jcp.org/en/jsr/detail?id=283 Hope this helps. Regards Felix On Wed, Dec 17, 2008 at 1:34 AM, Torgeir Veimo torg...@pobox.com wrote: On 17 Dec 2008, at 03:59, Rory Douglas wrote: As for the AccessManager, I think there are plans to upgrade Sling to Jackrabbit 1.5, so it may be more worthwhile to wait for that use the repository-ACL-based AccessManager that comes with 1.5 rather than implementing your own. Or ping me I can send you what I cobbled together for ACL-based control. ACLs are not suitable for most web applications. They're declarative, while most interactive web applications require implicit or application specific security constraints. Sling really needs to allow custom AccessManager implementations. -- Torgeir Veimo torg...@pobox.com
Re: Problems Implementing a Custom AccessManager
Hi Sebastien, Sebastian Gomez schrieb: Hi. Thanks for the answers. Is there any date scheduled for the upgrade to Jackrabbit 1.5? ACL was what I was thinking to use, so maybe the upgrade resolves my problem (although I haven't been able to find much documentation on ACL in 1.5 (if someone knows where I can find it I'll appreciate the indication). What worries me the most is that if ACL in 1.5 is not suitable enough for my app, what would be the way to go? As Alex said, I am already working on migrating Sling's Jackrabbit inclusion to 1.5. Now for documentation: There is the jackrabbit.apache.org site and there is a Jackrabbit Wiki. If you don't find any documentation there, it is probably best to just ask on the Jackrabbit dev or user list. Finally, since the Jackrabbit access control functionality is an implementation of the JSR-283 (JCR 2.0) access control functionality, you might find the appropriate description there. The public review draft is available from http://www.jcp.org/en/jsr/detail?id=283 Hope this helps. Regards Felix On Wed, Dec 17, 2008 at 1:34 AM, Torgeir Veimo torg...@pobox.com wrote: On 17 Dec 2008, at 03:59, Rory Douglas wrote: As for the AccessManager, I think there are plans to upgrade Sling to Jackrabbit 1.5, so it may be more worthwhile to wait for that use the repository-ACL-based AccessManager that comes with 1.5 rather than implementing your own. Or ping me I can send you what I cobbled together for ACL-based control. ACLs are not suitable for most web applications. They're declarative, while most interactive web applications require implicit or application specific security constraints. Sling really needs to allow custom AccessManager implementations. -- Torgeir Veimo torg...@pobox.com
Re: Problems Implementing a Custom AccessManager
On Wed, Dec 17, 2008 at 10:25 AM, Sebastian Gomez sage...@gmail.com wrote: Is there any date scheduled for the upgrade to Jackrabbit 1.5? See http://issues.apache.org/jira/browse/SLING-769 I think it will happen rather soon. Regards, Alex -- Alexander Klimetschek alexander.klimetsc...@day.com
Re: Problems Implementing a Custom AccessManager
Hi Sebastien,
The main problem with exporting from the jackrabbit-core library is,
that the service provider API (or internal API) like PersistenceManager
or AccessManager is not properly separated from the actual
implementation. Therefore just exporting everything is unsuitable
because it leeks too many implementation details into the framework.
In addition it causes really problematic dependency resolution issues
because not only jackrabbit-core packages must be exported but also
packages of helper libraries used by jackrabbit-core. Honestly it is a
nightmare of some sort ;-)
What you might want to do test, though, is just export the
org.apache.jackrabbit.core.security package, leaving the rest. To do
this just add the following lines to the configuration element of the
bundle plugin:
Export-Package
org.apache.jackrabbit.core.security
/Export-Package
Then rebuild the jackrabbit-core bundle and deploy it.
Please report back, whether this works, so we might well add this to the
setup in Sling.
Regards
Felix
Sebastian Gomez schrieb:
Hi everyone.
I'm trying to secure the JCR repository creating a custom LoginModule and
AccessManager. The first one has gone OK, as it implements the JAAS standard
interface. On the other hand, the second one must implement Jackrabbit's
AccessManager interface, but as Sling's Jackrabbit Embedded Repository
bundle does not export the jackrabbit-core packages (that includes the
AccessManager interface), the only way to create my custom implementation
has been to embed the dependency in my bundle's classpath. This then makes a
ClassCastException occur in Jackrabbit's SessionImpl when my class is being
casted to the AccessManager interface (line 335). As I guess you'll know,
this is because my CustomAccessManager is implementing the AccessManager
loaded by my bundle's classloader, while Jackrabbit's SessionImpl will
expect the AccessManager loaded by the Jackrabbit Embedded Repository
bundle.
I'd like to know if someone has already come up with (and hopefully
resolved) the same problem as I have, because I guess it's quite a common
scenario. The easiest solution would be to make the Sling's Jackrabbit
Embedded Repository bundle to export the security package of jackrabbit-core
but I suppose there must be some reason for it not to be doing so. I'll
appreciate any indication.
Thanks in advance.
Sebastian Gomez.
P.S: Here's the line of org.apache.jackrabbit.core.SessionImpl where the
ClassCastException occurs, marked with a = (in case it's of any use):
protected AccessManager createAccessManager(Subject subject,
HierarchyManager hierMgr)
throws AccessDeniedException, RepositoryException {
AccessManagerConfig amConfig =
rep.getConfig().getAccessManagerConfig();
try {
AMContext ctx = new AMContext(new
File(rep.getConfig().getHomeDir()),
rep.getFileSystem(),
subject,
hierMgr,
rep.getNamespaceRegistry(),
wsp.getName());
AccessManager accessMgr = (AccessManager)
amConfig.newInstance();
accessMgr.init(ctx);
return accessMgr;
} catch (AccessDeniedException ade) {
// re-throw
throw ade;
} catch (Exception e) {
// wrap in RepositoryException
String msg = failed to instantiate AccessManager
implementation: + amConfig.getClassName();
log.error(msg, e);
throw new RepositoryException(msg, e);
}
}
Re: Problems Implementing a Custom AccessManager
You may also need org.apache.jackrabbit.spi.* if you use some HierarchyManager methods (e.g. getPath) in your AccessManager. I added the snippet below to jackrabbit-server bundle's POM: Export-Package org.apache.jackrabbit.core.*, org.apache.jackrabbit.spi.* /Export-Package Sebastian Gomez wrote: Hi Felix. I tested what you told me, but I've seen it's not going to be possible only exporting org.apache.jackrabbit.core.security due to the fact that the AccessManager interface uses org.apache.jackrabbit.core.ItemId (so it will also need org.apache.jackrabbit.core exported, that by what you said I see is not an option). On the other hand I've had a look over the JSR-283 spec and the Jackrabbit 1.5 source code and it looks that it will include exactly what I need, so I think my best option is to hold on until you finish the migration. The thing is that I'm in a bit of a hurry with this part of my application, I've got my deadline quite near, so I hope you don't mind me daring to ask you how much time you estimate it will take (just to know if I can wait, or if I must implement this in some quickdirty way and expect an upgrade in the future). Thanks a lot for your help, and I hope you can help me out with this last doubt. Br, SebatiAn Gomez ;) On Wed, Dec 17, 2008 at 2:44 PM, Felix Meschberger fmesc...@gmail.comwrote: Hi Sebastien, Sebastian Gomez schrieb: Hi. Thanks for the answers. Is there any date scheduled for the upgrade to Jackrabbit 1.5? ACL was what I was thinking to use, so maybe the upgrade resolves my problem (although I haven't been able to find much documentation on ACL in 1.5 (if someone knows where I can find it I'll appreciate the indication). What worries me the most is that if ACL in 1.5 is not suitable enough for my app, what would be the way to go? As Alex said, I am already working on migrating Sling's Jackrabbit inclusion to 1.5. Now for documentation: There is the jackrabbit.apache.org site and there is a Jackrabbit Wiki. If you don't find any documentation there, it is probably best to just ask on the Jackrabbit dev or user list. Finally, since the Jackrabbit access control functionality is an implementation of the JSR-283 (JCR 2.0) access control functionality, you might find the appropriate description there. The public review draft is available from http://www.jcp.org/en/jsr/detail?id=283 Hope this helps. Regards Felix On Wed, Dec 17, 2008 at 1:34 AM, Torgeir Veimo torg...@pobox.com wrote: On 17 Dec 2008, at 03:59, Rory Douglas wrote: As for the AccessManager, I think there are plans to upgrade Sling to Jackrabbit 1.5, so it may be more worthwhile to wait for that use the repository-ACL-based AccessManager that comes with 1.5 rather than implementing your own. Or ping me I can send you what I cobbled together for ACL-based control. ACLs are not suitable for most web applications. They're declarative, while most interactive web applications require implicit or application specific security constraints. Sling really needs to allow custom AccessManager implementations. -- Torgeir Veimo torg...@pobox.com -- Rory Douglas | Senior Principal Consultant Fax: +1-201-604-6428 | Mobile: +1-917-498-5344 Oracle North America Consulting ORACLE United States | | San Diego, CA Please consider your environmental responsibility before printing this e-mail
Problems Implementing a Custom AccessManager
Hi everyone.
I'm trying to secure the JCR repository creating a custom LoginModule and
AccessManager. The first one has gone OK, as it implements the JAAS standard
interface. On the other hand, the second one must implement Jackrabbit's
AccessManager interface, but as Sling's Jackrabbit Embedded Repository
bundle does not export the jackrabbit-core packages (that includes the
AccessManager interface), the only way to create my custom implementation
has been to embed the dependency in my bundle's classpath. This then makes a
ClassCastException occur in Jackrabbit's SessionImpl when my class is being
casted to the AccessManager interface (line 335). As I guess you'll know,
this is because my CustomAccessManager is implementing the AccessManager
loaded by my bundle's classloader, while Jackrabbit's SessionImpl will
expect the AccessManager loaded by the Jackrabbit Embedded Repository
bundle.
I'd like to know if someone has already come up with (and hopefully
resolved) the same problem as I have, because I guess it's quite a common
scenario. The easiest solution would be to make the Sling's Jackrabbit
Embedded Repository bundle to export the security package of jackrabbit-core
but I suppose there must be some reason for it not to be doing so. I'll
appreciate any indication.
Thanks in advance.
Sebastian Gomez.
P.S: Here's the line of org.apache.jackrabbit.core.SessionImpl where the
ClassCastException occurs, marked with a = (in case it's of any use):
protected AccessManager createAccessManager(Subject subject,
HierarchyManager hierMgr)
throws AccessDeniedException, RepositoryException {
AccessManagerConfig amConfig =
rep.getConfig().getAccessManagerConfig();
try {
AMContext ctx = new AMContext(new
File(rep.getConfig().getHomeDir()),
rep.getFileSystem(),
subject,
hierMgr,
rep.getNamespaceRegistry(),
wsp.getName());
AccessManager accessMgr = (AccessManager)
amConfig.newInstance();
accessMgr.init(ctx);
return accessMgr;
} catch (AccessDeniedException ade) {
// re-throw
throw ade;
} catch (Exception e) {
// wrap in RepositoryException
String msg = failed to instantiate AccessManager
implementation: + amConfig.getClassName();
log.error(msg, e);
throw new RepositoryException(msg, e);
}
}
Re: Problems Implementing a Custom AccessManager
Hi Sebastian
I went this route back in August, and came up against the same problems
(see [1]). I had the AccessManager working by exporting the .spi
classes from Sling's Jackrabbit bundle, but would intermittently run
into issues with the JAAS LoginModule after restarts. I think there may
be a need to specify the JAAS classes so they are added to the
system/framework classpath using sling.properties, but I don't
understand that mechanism couldn't get it work. I ultimately
abandoned work on this because it didn't seem the right approach (as
Felix points out) to depend on non-API classes from the underlying
repository.
As for the AccessManager, I think there are plans to upgrade Sling to
Jackrabbit 1.5, so it may be more worthwhile to wait for that use the
repository-ACL-based AccessManager that comes with 1.5 rather than
implementing your own. Or ping me I can send you what I cobbled
together for ACL-based control.
Regards,
Rory
[1] http://markmail.org/message/ejzb4vk6nypmrf5s
Sebastian Gomez wrote:
Hi everyone.
I'm trying to secure the JCR repository creating a custom LoginModule and
AccessManager. The first one has gone OK, as it implements the JAAS standard
interface. On the other hand, the second one must implement Jackrabbit's
AccessManager interface, but as Sling's Jackrabbit Embedded Repository
bundle does not export the jackrabbit-core packages (that includes the
AccessManager interface), the only way to create my custom implementation
has been to embed the dependency in my bundle's classpath. This then makes a
ClassCastException occur in Jackrabbit's SessionImpl when my class is being
casted to the AccessManager interface (line 335). As I guess you'll know,
this is because my CustomAccessManager is implementing the AccessManager
loaded by my bundle's classloader, while Jackrabbit's SessionImpl will
expect the AccessManager loaded by the Jackrabbit Embedded Repository
bundle.
I'd like to know if someone has already come up with (and hopefully
resolved) the same problem as I have, because I guess it's quite a common
scenario. The easiest solution would be to make the Sling's Jackrabbit
Embedded Repository bundle to export the security package of jackrabbit-core
but I suppose there must be some reason for it not to be doing so. I'll
appreciate any indication.
Thanks in advance.
Sebastian Gomez.
P.S: Here's the line of org.apache.jackrabbit.core.SessionImpl where the
ClassCastException occurs, marked with a = (in case it's of any use):
protected AccessManager createAccessManager(Subject subject,
HierarchyManager hierMgr)
throws AccessDeniedException, RepositoryException {
AccessManagerConfig amConfig =
rep.getConfig().getAccessManagerConfig();
try {
AMContext ctx = new AMContext(new
File(rep.getConfig().getHomeDir()),
rep.getFileSystem(),
subject,
hierMgr,
rep.getNamespaceRegistry(),
wsp.getName());
AccessManager accessMgr = (AccessManager)
amConfig.newInstance();
accessMgr.init(ctx);
return accessMgr;
} catch (AccessDeniedException ade) {
// re-throw
throw ade;
} catch (Exception e) {
// wrap in RepositoryException
String msg = failed to instantiate AccessManager
implementation: + amConfig.getClassName();
log.error(msg, e);
throw new RepositoryException(msg, e);
}
}
Re: Problems Implementing a Custom AccessManager
On 17 Dec 2008, at 03:59, Rory Douglas wrote: As for the AccessManager, I think there are plans to upgrade Sling to Jackrabbit 1.5, so it may be more worthwhile to wait for that use the repository-ACL-based AccessManager that comes with 1.5 rather than implementing your own. Or ping me I can send you what I cobbled together for ACL-based control. ACLs are not suitable for most web applications. They're declarative, while most interactive web applications require implicit or application specific security constraints. Sling really needs to allow custom AccessManager implementations. -- Torgeir Veimo torg...@pobox.com
