[JBoss JIRA] Created: (JBAS-3976) Stateful Session Bean throws a Null Security Context exception with no login
by Anil Saldhana (JIRA)
Stateful Session Bean throws a Null Security Context exception with no login
----------------------------------------------------------------------------
Key: JBAS-3976
URL: http://jira.jboss.com/jira/browse/JBAS-3976
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Security
Affects Versions: JBossAS-5.0.0.Beta1, JBossAS-4.0.5.GA
Reporter: Anil Saldhana
Assigned To: Anil Saldhana
Fix For: JBossAS-5.0.0.Beta2, JBossAS-4.2.0.CR1, JBossAS-4.0.5.SP1
Since the stateful session bean instance interceptor happens before the security interceptor (security exceptions need to invalidate the session), the call to set the principal on the enterprise context can fail when the bean was invoked with no login. Remember the getCallerPrincipal call on the context needs to always return a non-null principal.
If the setting of the principal on the context happens after the security checks have been made via the security interceptor, there is security domain settings reflected via the unauthenticated principal setting on the domain into the principal to be set on the context.
Of course the user can always specify the unauthenticated-principal tag in jboss-app.xml/jboss.xml DD but this should not be mandatory.
There is a need for a new interceptor after the security interceptor.
--
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
17 years, 1 month
[JBoss JIRA] Updated: (JBAS-2482) Investigate integration of FORM auth with a SAML style identity provider
by Anil Saldhana (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-2482?page=all ]
Anil Saldhana updated JBAS-2482:
--------------------------------
Component/s: Security
Web (Tomcat) service
Fix Version/s: JBossAS-5.0.1.CR1
(was: JBossAS-5.0.0.Beta3)
> Investigate integration of FORM auth with a SAML style identity provider
> ------------------------------------------------------------------------
>
> Key: JBAS-2482
> URL: http://jira.jboss.com/jira/browse/JBAS-2482
> Project: JBoss Application Server
> Issue Type: Sub-task
> Security Level: Public(Everyone can see)
> Components: Web (Tomcat) service, Security
> Reporter: Scott M Stark
> Assigned To: Anil Saldhana
> Fix For: JBossAS-5.0.1.CR1
>
>
> We need to investigate how one can update the FORM authentication layer to delegate the authentication to an identity provider. Issues include:
> 1. authentication of the form username/password
> 2. authentication of an existing login from another app using SSO
> 3. reauthentication if the web session outlives the IDP token validity
> 4. propagation of the identity to other secure components.
--
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
17 years, 1 month
[JBoss JIRA] Created: (JBAS-4950) Transaction failover authorisation is broken within UnifiedInvokerHAProxy
by Galder Zamarreno (JIRA)
Transaction failover authorisation is broken within UnifiedInvokerHAProxy
-------------------------------------------------------------------------
Key: JBAS-4950
URL: http://jira.jboss.com/jira/browse/JBAS-4950
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Clustering, Remoting
Affects Versions: JBossAS-4.2.2.GA, JBossAS-5.0.0.Beta2
Reporter: Galder Zamarreno
Assigned To: Brian Stansberry
UnifiedInvokerHAProxy.invoke() only calls invocationHasReachedAServer(Invocation invocation)
if GenericClusteringException is received and the exception is not GenericClusteringException.COMPLETED_NO
This is not correct because invocationHasReachedAServer(Invocation invocation) needs to be called on
successful returns as well. If we don't, the code never remembers that a call within a transaction was
successful and therefore, never adds the potential transaction (with JBAS-4455, this will transaction propagation context)
associated with the call to the failover map authorisations.
Example:
- ok call 1 within tx1
- ok call 2 within tx1
- ok call 3 within tx1
- fail call 4 with GenericClusteringException.COMPLETED_NO
None of the successfull calls updated the map, so when the 4 call occurs, txContextAllowsFailover(invocation) is called, but
the map is empty, so would allow failover when it shouldn't. A transaction reached the server already in any of the previous
calls associated with that transaction.
JRMPInvokerProxyHA does not have this issue.
--
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
17 years, 1 month
[JBoss JIRA] Created: (EJBTHREE-1108) The EJB3 Consumer test is not thread safe
by Adrian Brock (JIRA)
The EJB3 Consumer test is not thread safe
-----------------------------------------
Key: EJBTHREE-1108
URL: http://jira.jboss.com/jira/browse/EJBTHREE-1108
Project: EJB 3.0
Issue Type: Task
Reporter: Adrian Brock
Assigned To: Adrian Brock
Fix For: AS 5.0.0.Beta3
The EJB3 Consumer testQueueXA appears to be checking that method2 is invoked after method1.
However, it creates an ActivationSpec with the default maxSession=15
which means methods can compete with each other to be delivered on upto 15 threads.
It needs changing to be single threaded delivery to consistently pass this test.
@Consumer(activationConfig =
{
@ActivationConfigProperty(propertyName="destinationType", propertyValue="javax.jms.Queue"),
@ActivationConfigProperty(propertyName="destination", propertyValue="queue/mdbtest"),
+ @ActivationConfigProperty(propertyName="maxSession", propertyValue="1")
})
public class QueueTestConsumer implements QueueTestRemote, QueueTestXA, QueueTestLocal
--
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
17 years, 1 month
[JBoss JIRA] Commented: (JBAS-2235) Server Controller Tasks: Throw error if normal shutdown fails
by Dimitris Andreadis (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-2235?page=comments#action_12387340 ]
Dimitris Andreadis commented on JBAS-2235:
------------------------------------------
Let me recap my take:
1) I want the build to continue. When the whole testsuite takes 4+ hours to complete I don't want a small mistake in one custom configuration to ruin all the results. Now if we can somehow highlight that we have a server start/stop problem, that would be nice.
2) Adrian's idea should be tried out.
- try a normal shutdown (with a timeout)
- try a -H shutdown (force the JVM to halt)
- kill the process
> Server Controller Tasks: Throw error if normal shutdown fails
> -------------------------------------------------------------
>
> Key: JBAS-2235
> URL: http://jira.jboss.com/jira/browse/JBAS-2235
> Project: JBoss Application Server
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Test Suite
> Environment: jboss-4.0 tip
> Reporter: Ryan Campbell
> Assigned To: Martin Vecera
> Fix For: JBossAS-5.0.0.Beta3
>
>
> Currently, when a server fails to respond to a shutdown request, the process is killed and the tests continue.
> There should be an error thrown if the server fails to shutdown within the timeout period.
--
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
17 years, 1 month