docs: 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;
      }