Hi
>> 1) Why is Glassfish not made, so that it is possible to make
>> programmatic login the standard way?
>You may be in a J2SE environment and invoking a remote secure EJB, in
>such cases you do need some API. And it is best if the same API is
>usable elsewhere rather than having different API's for different places.
Why is that? You should be able to do the login as explained on the
remote client (J2SE environment) and then make your remote EJB call.
SecurityContext must be propagated from the client to the server over
RMI/IIOP, so if the client makes the login as I explains, then that
login will be propagated to the server and the code over there will be
executed in context of the logged in user.
>> 2) Why does Glassfish invent a SecurityContext class to to hold the
>> current Subject, when that is supposed to be set by Subject.doAs
> From what i remember talking to our architect, there is a performance
>impact in trying to access the Subject from the AccessControlContext,
>especially when the SecurityManager is ON. This overhead is circumvented
>by the use of SecurityContext.
Ok, but it just violates the fact the AccessControlContext IS the way
JAAS is designed to be used. You cannot say that Glassfish is using
JAAS/is JAAS compliant (and I guess that i part of the Java EE spec that
you should be) if it does not use JAAS correctly and in the intended
ways. Being JAAS compliant means that JAAS should be used the "right"
way so that developers of Glassfish applications can do security stuff
the "right" JAAS way. You cannot just invent your own stuff and end up
in a situation where the developers of Glassfish application cannot
expect that the server uses JAAS the way it is intended to be used.
>> I know that I could simplify my login method by using the
>> ProgrammaticLogin class, but it will not change the existence of the
>> problems mentioned below.
>>
>But you are better off using ProgrammaticLogin here because it is an
>exposed/supported Proprietary API whereas the code you have above might
>change.
Ofcause I agree. But I really shouldnt be forced to do anything
Glassfish-specific stuff. Especially not when it actually is on the
server-side itself (not on a remote client) that I want to do my
programmic login.
>> LoginContext lc = login(username, password);
>> Subject.doAs(lc.getSubject(), <call my business-login on secured EJBs
>> packed in a PrivilegedAction>);
>>
>Can you be sure that doing it this way will work on all other JavaEE
>Server's (yes doing it this way you are atleast using standard Java SE
>API's but that does not guarantee that all JavaEE server's will work
>when used this way, though i agree it would be ideal if they did).
I do not know exactly what the Java EE spec says, but I am pretty sure
that it mentions something about security should be supported by a Java
EE server using JAAS the-JAAS-way. And even if it does not, I would
expect the most Java EE server vendors chooses to use JAAS the way it
was intended to be used. I my opinion it is a obviois must to do it that
way.