java ee - Authentication of user through the Application client container in GlassFish is too ambitious? -

problem

when inject @ejb proxy in main class of application client, , ejb has method require user in role, application client container (acc) require user login application client launches. acc not differentiate between methods client had in mind calling, roles - if @ - required of client in. in effect, means client cannot hook himself server if 1 single method of ejb has method require role. not matter if explicitly annotate ejb @permitall. acc still prompt username , password, , if not given, glassfish 3.1.2.2 (build 5) implementation abort , "the user cancelled authentication".

setup test environment!

declare remote interface so:

@remote public interface iremoteejb { string echoguest(string returnme); string echoadmin(string returnme); } 

write ejb (my problem relates singleton dare not use session annotation here!):

@singleton /*  * see following annotation. explicitly "permit all" on class level.  * should not cause ambiguity @ all!  */ @permitall public class myejb implements iremoteejb {     @override     public string echoguest(string returnme) {         return returnme; }      @override     // ..but here grant access administrators:     @rolesallowed("admin")     public string echoadmin(string returnme) {         return returnme; } } 

as client part, here's smallest possible implementation think of:

public class main {     @ejb private static remoteproxy;      public static void main(string... args)     {         string reply = remoteproxy.echoguest("hello world!");         joptionpane.showmessagedialog(null, reply);     } } 

result

do think client makes "anonymous" call echoguest method? no. i've found acc force client give username , password before @ejb injected. put if, cannot mix access authentication ejb application client. solution above remove @rolesallowed("admin") annotation echoadmin method.

in 1 way, makes sense. acc active during boot of client, reason why need put injected resources in application client both in main class , make them static too. acc cannot know methods in ejb invoked or not.

okay, not break specification , expected behavior of @permitall , @rolesallowed annotations? there no way on earth provide application client anonymous access rights ejb has 1 obsolete, never invoked, method requiring role? of now, have separate these methods not annotations thought , should have done, have refactor logic separate ejb:s. feels hard :'(

the java ee 7 specification jsr 342 says on page 9, application client's deployment , management not defined specification. can expect different, non-portable behavior when comes "management" of application clients.

the specification continues , talk lazy authentication on pages 41 , 42:

there cost associated authentication. example, authentication process may require exchanging multiple messages across network. therefore, desirable use lazy authentication, is, perform authentication when needed. lazy authentication, user not required authenticate until there request access protected resource.

lazy authentication can used first-tier clients (applets, application clients) when request access protected resources require authentication.

i cannot parse quote , judge whether lazy authentication required specification or not. apparently, not. is, glassfish not break rule when require authentication our application client before accessed protected resource (a method invocation in example).

moreover, specification hit hurts on page 44:

the techniques used may vary implementation of application client container, , beyond control of application

thus final judgement must specification not require lazy authentication , "techniques" may vary.