The Java EE 7 specification JSR 342 says on page 9, that application client's deployment and management is not completely defined by this specification
. Thus we can expect different, non-portable behavior when it comes to the "management" of application clients.
The specification continues and talk about Lazy Authentication on pages 41 and 42:
There is a cost associated with authentication. For example, an authentication process may require exchanging multiple messages across the network. Therefore, it is desirable to use lazy authentication, that is, to perform authentication only when it is needed. With lazy authentication, a user is not required to authenticate until there is a request to access a protected resource.
Lazy authentication can be used with first-tier clients (applets, application clients) when they request access to protected resources that require authentication.
I cannot parse this quote and judge whether Lazy Authentication is required by the specification or not. Apparently, it is not. That is, GlassFish do not break any rule when he require authentication from our application client even before we accessed the protected resource (a method invocation in the example).
Moreover, the specification really hit where it hurts on page 44:
The techniques used may vary with the implementation of the application client container, and are beyond the control of the application
Thus my final judgement must be that the specification does not require lazy authentication and that "techniques" may vary.