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
>
>