private boolean isInternalUnprotectedMethod ( EJBMethodMetaData methodMetaData ) { EJBMethodInterface interfaceType = methodMetaData . getEJBMethodInterface ( ) ; /*** * For TIMED_OBJECT, the code references EJB 2.1 spec section 22.2.2 and matches a * method signature, which is necessary but not sufficient. As of EJB 3.0, the * TimedObject interface is not necessary and arbitrary methods can be designated * as timeout callback methods using the @Timeout annotation. Further, the EJB * 3.1 spec adds the ability to specify timeout methods without a Timer argument, * and it also adds new timeout callback methods via the @Schedule annotation. In * all of these cases, the MethodInterface will be TIMED_OBJECT. * * For LIFECYCLE_INTERCEPTOR, this type is used only for lifecycle interceptors of * EJB 3.1 singleton session beans. This type should have been added to the EJB 3.1 * spec, but it was overlooked by the EG. However, EJB container needs to classify * methods in this way, so an internal type was added. * * For background on why returning true from internalUnprotected is correct for * LIFECYCLE_INTERCEPTOR, a singleton method invocation has two steps, and the * container invokes the security collaborator for each. * * 1. Obtain the bean instance if it does not already exist. * If the bean does not exist, the container calls the security collaborator * with LifecycleInterceptor to establish a RunAs security context. However, * authorization checks are not needed because the bean is performing * initialization, not business logic. Further, attempting to pass the * internal-only LifecycleInterceptor type to JACC causes an * IllegalArgumentException. * * If a singleton session bean is annotated @Startup, then the container * performs this step as part of application start rather than when a method * is first invoked on the bean. This is the scenario for this defect. * * 2. Invoke the business method. * The container calls the security collaborator "as normal" with Local, * Remote, or ServiceEndpoint to both authorize the caller security context * and to establish a RunAs security context as needed. * * Per EJB spec section 22.2.2: * * Since the ejbTimeout method is an internal method of the bean class, * it has no client security context. When getCallerPrincipal is called * from within the ejbTimeout method, it returns the container * representation of the unauthenticated identity. * Since the ejbTimeout method is an internal method of the bean class, * it has no client security context. The Bean Provider should use the * run-as deployment descriptor element to specify a security identity to * be used for the invocation of methods from within the ejbTimeout method. * * Because of the above spec requirements, we still need to establish the * runasSpecified identity when this method is called. **/ if ( EJBMethodInterface . LIFECYCLE_INTERCEPTOR . value ( ) == ( interfaceType . value ( ) ) || EJBMethodInterface . TIMER . value ( ) == ( interfaceType . value ( ) ) ) { return true ; //TODO: should this logic go into ejb container? } return false ; }
Check if the methodMetaData interface is internal and supposed to be unprotected as per spec .