Hi
We never got a comment from Ron!?
Regards, Per Steffensen
Kumar Jayanti skrev:
> <div class="moz-text-flowed" style="font-family: -moz-fixed">Hi,
> I am CCing Ron Monzillo who might be able to clarify the spec
> related thing that you mention.
>
>
> Per Steffensen wrote:
>> 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.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>
>>
>
> </div>