[JBoss JIRA] Updated: (JBCACHE-404) Provide API to allow multiple callers to safely call activateRegion() .
by Brian Stansberry (JIRA)
[ http://jira.jboss.com/jira/browse/JBCACHE-404?page=all ]
Brian Stansberry updated JBCACHE-404:
-------------------------------------
Fix Version/s: 2.0.0.CR1
(was: 2.0.0.BETA2)
> Provide API to allow multiple callers to safely call activateRegion() .
> -----------------------------------------------------------------------
>
> Key: JBCACHE-404
> URL: http://jira.jboss.com/jira/browse/JBCACHE-404
> Project: JBoss Cache
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Affects Versions: 1.2.4SP1, 1.2.4
> Reporter: Brian Stansberry
> Assigned To: Brian Stansberry
> Priority: Minor
> Fix For: 2.0.0.CR1
>
>
> If a caller calls activateRegion() and the region is already active, they will get a RegionNotEmptyException. Need to add an API to make it easy for use cases where multiple callers may want to activate the same region.
> Use case for this is ClusteredSSO. Multiple ClusteredSSO valves can be running in the same server; all share the /SSO region. The TreeCache is shared with session replication, so the activateRegion API needs to be used. Currently it catches the RegionNotEmptyException, but I don't like this in the ClusteredSSO code.
> Possibilities:
> 1) Add an isRegionActive() method, callers can check first. But this can lead to race conditions.
> 2) Overload the activateRegion method with a version that won't throw the RegionNotEmptyException.
> Don't want to get rid of the RegionNotEmptyException, as in many uses cases (e.g. session repl) the region should not have data; if it does that's an error condition the application should know about.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 2 months
[JBoss JIRA] Created: (JBAS-4003) using run-as causes anonymous principal to be propagated across EARs and security domains
by Michal Borowiecki (JIRA)
using run-as causes anonymous principal to be propagated across EARs and security domains
-----------------------------------------------------------------------------------------
Key: JBAS-4003
URL: http://jira.jboss.com/jira/browse/JBAS-4003
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: JBossAS-4.0.5.GA
Reporter: Michal Borowiecki
Using run-as causes anonymous principal to be propagated across EARs and security domains.
I have a MDB in EAR 1 with run-as configured.
It calls a session bean in the same EAR and the reported identity in the target session bean's method is anonymous, which is OK.
The session bean then calls another session bean in another EAR which is in a different security-domain.
A ClientLoginModule is used to authenticate in the other security domain.
Nevertheless, the target bean sees the caller as anonymous, with the role configured as run-as in EAR1.
The same code works OK when run-as is removed from configuration.
I understand that the run-as role with anonymous identity is propagated across subsequent ejb calls, however it should not be propagated when explicit login is used on some other security domain. After all, the whole point of authenticating into a security domain is to establish an identity in that domain. It seems that the newly established identity is ignored in favour of the run-as identity and role propagated from the original security domain.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 2 months