We do not have the problem that you describe.
Why? Because we do not let the container perform the authentication.
We handle authentication *entirely* in our own code, and completely
ignore the J2EE/container authentication. Thus, our servlets always
access the EJB SB's using a single user/password that is assigned to
the servlet. The user/password are not known outside of the company.
As I indicated in my previous posting, we handle everything in the
SB's with our own UserSession entity bean. When a user logs in, they
get a UserSession EB that determines their priveleges. The privelege
is handled entirely within our code. We do not use container privelege
at all except to secure the handful of methods involved in establishing
the UserSession.
This design has eliminated almost every complaint that people have posted
regarding container authentication, priveleges, and sessions. Further, it
allows us to implement "higher level" permission management that can not
be managed by the container (such as, can this user modify a record based
on their relationship to the owner of the record).
tim.
> As with anything, the devil is in the details.
>
> SBs expire in one of a number of ways. The two main ways are: you call
> remove() or they time out. This is well known. So if you have your SB bound
> to an HttpSession, everything works and you get get your SB from the session
> at any time.
>
> The REAL ISSUE is, however, the security issues with how you clean up that
> SB when the HttpSession expires. This is something it seems no one really
> understands, and it seems to me to be a fairly critical to the proper
> working of J2EE.
>
> The servlet spec does not say anything about WHO calls
> HttpSessionBindingListener.valueUnbound() when an HttpSession expires.
> Assume (arbitrarly) that it is an "unauthenticated user" (Orion calls this a
> "guest"), then if you call ejb.remove() within valueUnbound(), the EJB will
> be called with the guest user. Well, what if the remove() method is
> protected by security constraints and guest is not allowed? What if you had
> to call other methods to clean up that session?
>
> Well, someone said "log in with a special user before calling remove()". It
> doesn't work because one tries to JNDI-lookup a RoleManager to log in, Orion
> throws an exception saying "javax.naming.NamingException: Not in an
> application scope". Okay, so just call remove() and do the login in there.
> That DID work, but WHY? I have my remove() method secured so only
> authenticated users can hit it. And what if you had to call OTHER methods in
> addition to remove()?
>
> From the responses, it seems either that no one has previously recognized
> this as a problem, or that they're ignoring it, or I'm just all wrong.
>
> So please, am I wrong, or is there an issue here?
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Petr Podsednik
> Sent: Friday, March 23, 2001 12:37 AM
> To: Orion-Interest
> Subject: Re: Removing SBs when expiring HttpSessions ... the challenge
> continues.
>
>
> Hi,
> If It is possible I have a question regarding this problem.
> Until now I was thinking there is no problem regarding HttpSession expiring
> because of garbage collector which knows what remote references became
> invalid. Please tell me, if I am wrong and why. If it is must be handled in
> code what about for example Swing clients machine's crashing?
> Regards
> Petr
>
> > When an HttpSession expires, it calls valueUnbound() on all session-bound
> > variables that implement the HttpSessionBindingListener interface. So this
> > provides a way for expiring HTTP sessions to remove session beans that
> would
> > otherwise stay active and eventually consume all resources and cause the
> > server to crash.
