[Security & JAAS/JBoss] - JBoss 4.2.3: non-compliant behavior of JACC implementation?
by kcg
Hello,
I'm porting our custom JACC provider to JBoss. For access control I've found that JBoss is using not recommended practice of calling `getPermission' on policy provider. JACC 1.0 final release specification claims that after this call container must call `implies' method on the returned PermissionCollection object. My debug messages proof that this is not the case with JBoss 4.2.3GA. For your reference, this is ``4.8 Checking the Caller for a Permission'' specification paragraph, where someone might read: anonymous wrote : The J2EE 1.4 container calls
| java.security.Policy.getPermissions with an argument
| ProtectionDomain that was constructed with the principals of the caller. The
| container must call the implies method on the returned
| PermissionCollection using the permission being checked as argument. If the
| PermissionCollection implies the permission being tested, the permission has
| been granted to the caller. Otherwise it has not. This technique is supported but
| not recommended.
Am I doing anything wrong or is it really a non-compliant bit of JBoss JACC implementation?
Our JACC provider is written in a way that it requires to have `implies' called on the policy provider. So I written simple facade PermissionCollection which behave like normal permission collection, but delegates it's implies to the policy provider. The problem is, its `implies' is not called. Do you have any idea how to convience JBoss to call either implies on the returned value from getPermission or implies directly on the policy provider?
Thanks!
Karelanonymous wrote :
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206710#4206710
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206710
17 years, 2 months
[JBoss Cache: Core Edition] - Re: Problems with Transaction Manager
by fatboysuns
One more thing, I tried to start a thread which would act as the loader. I tried this stupid approach of making it sleep for some time and then call the method to load the cache. The idea being that the cache would get evoked only after the server started up and the jboss transaction manager would be in place.
Even after doing this, the cache was getting bound to dummytransactionManager only. My code was
private boolean retryAndLoadCache(Thread t) {
for (int i = 0; i < 3; i++) {
try {
t.sleep(20000);
boolean cacheLoaded = checkIfCacheLoaded(); //sets up the configuration for my singleton cache object
if (cacheLoaded) {
return true;
} else {
cacheFactory.destroyCache(); // calls cache.destroy and makes the cache object back to null.
log.info("destroying cache");
}
} catch (NameAlreadyBoundException nabe) {
//log.error(nabe, nabe);
log.info("Retrying " + i + "th time.");
} catch (InterruptedException e) {
log.error(e, e);
}
}
return false;
}
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206699#4206699
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206699
17 years, 2 months