EJBAccessException

[GoogleCodeExporter]

I can't access EJB with @RolesAllowed.

What steps will reproduce the problem?
1. Create a sip servlet with restricted access based on digest authentication;
2. Create a stateless session bean annotated with @RolesAllowed("USER");
3. In the doInvite call the EJB;
4. Try to send an INVITE: the servlet answer with a 401 error response;
5. Resend the INVITE supplying the right credential;
6. mobicents correctly set principal and roles but it is unable to call the EJB:

javax.ejb.EJBAccessException: JBAS014502: Invocation on method: public 
java.lang.String example.SimpleEJB.helloWorld() of bean: ConnectionFacade is 
not allowed
    at org.jboss.as.ejb3.security.AuthorizationInterceptor.processInvocation(AuthorizationInterceptor.java:101)
    at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
    at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:76)
    at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
    at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:42)
    at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
    at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59)
    at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
    at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
    at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
    at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:32)
    at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
    at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45)
    at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
    at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
    at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)
    at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:176)
    at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
    at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
    at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:72)
    at example.SimpleEJB$$$view8.helloWorld(Unknown Source)
    at example.SimpleSipServlet.doInvite(SimpleSipServlet.java:61)
    at javax.servlet.sip.SipServlet.doRequest(SipServlet.java:231)
    at javax.servlet.sip.SipServlet.service(SipServlet.java:328)
    at org.mobicents.servlet.sip.core.dispatchers.MessageDispatcher.callServlet(MessageDispatcher.java:367)
    at org.mobicents.servlet.sip.core.dispatchers.InitialRequestDispatcher$InitialDispatchTask.dispatch(InitialRequestDispatcher.java:795)
    at org.mobicents.servlet.sip.core.dispatchers.DispatchTask.dispatchAndHandleExceptions(DispatchTask.java:61)
    at org.mobicents.servlet.sip.core.dispatchers.InitialRequestDispatcher.dispatchInsideContainer(InitialRequestDispatcher.java:449)
    at org.mobicents.servlet.sip.core.dispatchers.InitialRequestDispatcher.dispatchMessage(InitialRequestDispatcher.java:310)
    at org.mobicents.servlet.sip.core.SipApplicationDispatcherImpl.processRequest(SipApplicationDispatcherImpl.java:770)
    at gov.nist.javax.sip.EventScanner.deliverEvent(EventScanner.java:230)
    at gov.nist.javax.sip.SipProviderImpl.handleEvent(SipProviderImpl.java:185)
    at gov.nist.javax.sip.DialogFilter.processRequest(DialogFilter.java:1321)
    at gov.nist.javax.sip.stack.SIPServerTransaction.processRequest(SIPServerTransaction.java:864)
    at gov.nist.javax.sip.stack.UDPMessageChannel.processMessage(UDPMessageChannel.java:559)
    at gov.nist.javax.sip.stack.UDPMessageChannel.processIncomingDataPacket(UDPMessageChannel.java:511)
    at gov.nist.javax.sip.stack.UDPMessageChannel.run(UDPMessageChannel.java:316)
    at java.lang.Thread.run(Thread.java:744)

What version of the product are you using? On what operating system?
mss-2.0.0.FINAL-jboss-as-7.1.2.Final

Please provide any additional information below.
I tried to take a look at the code and the problem could be in 
org.mobicents.servlet.sip.catalina.security.authentication.DigestAuthenticator

------ CODE --------
SecurityContext sc = SecurityActions.getSecurityContext();
        if (sc == null) {
            if (log.isDebugEnabled()) {
                log.debug("Security Domain " + securityDomain + " for Realm " + realmName);
            }
            if (securityDomain == null) {
                if (log.isDebugEnabled()) {
                    log.debug("Security Domain is null using default security domain " + SIPSecurityConstants.DEFAULT_SIP_APPLICATION_POLICY + " for Realm " + realmName);
                }
                securityDomain = SIPSecurityConstants.DEFAULT_SIP_APPLICATION_POLICY;
            }
            sc = SecurityActions.createSecurityContext(securityDomain);
            SecurityActions.setSecurityContextOnAssociation(sc);
        }

        try {
            return (new CatalinaSipPrincipal(realm.authenticate(userName, response, nOnce, nc, cnonce, qop, realmName, md5a2)));
        } finally {        
            SecurityActions.clearSecurityContext();
            SecurityRolesAssociation.setSecurityRoles(null);
        }

----- END CODE -------

before returning it clears the security context. If I remove the finally block 
it works. 

That piece of code was taken from a jboss valve. In that case the security 
context is cleared when the control returns back from the pipeline:

---- CODE -------
try {
    getNext().invoke(request, response);
} finally {        
    SecurityActions.clearSecurityContext();
    SecurityRolesAssociation.setSecurityRoles(null);
}
----- END CODE -------

As far as I understand the DigestAuthenticator and the EJB calling follow 
different paths so I can't figure out where can be a common point to set and 
destroy the security context.

Original issue reported on code.google.com by messa...@gmail.com on 6 Nov 2013 at 8:25

[GoogleCodeExporter]

Can you provide a sample application that reproduces the problem ? That would 
help debugging the problem faster and thanks for the tentative patch. Those 
calls were used for JBoss 5 to clear the SecurityContext as it would cause a 
leak otherwise so make sure to profile after those fixes and check no Seucrity 
classes are being kept in memory and leaking

Original comment by jean.deruelle on 8 Nov 2013 at 1:56

• Changed state: Accepted

[GoogleCodeExporter]

It is an ear project with an integration test based on sipunit. I structured it 
as an ear so you can use it for the issue 241 too. There is a README file with 
some instructions.

Original comment by messa...@gmail.com on 9 Nov 2013 at 3:42

Attachments:

• ejbtest.zip

[GoogleCodeExporter]

Issue was moved to GitHub:

https://github.com/Mobicents/sip-servlets/issues/33

Original comment by desi.pep...@telestax.com on 18 Dec 2014 at 6:51

[GoogleCodeExporter]

Original comment by jean.deruelle on 18 Dec 2014 at 9:26

• Changed state: Moved