Access client security information

[Sudhir V]

I am having trouble understanding "when can one access security information about the client" in case of entity beans. It was kind of easy in session beans coz the whole thing used to revolve around the EJBObject (lifeline to the client).
Example: Why cannot we obtain the client security information in the EJBActivate method of entity bean. Any generic logic which can be applied in every case?
Sudhir

[Reid M. Pinchback]

I think of it this way...
The point of ejbActivate is to get the bean instance back to the state it was in just before ejbPassivate. You can't passivate if you've got a client, so if activation gets you back to that original state... you still don't have a client. No client, hence no client security info. Activation gets the instance to a point where it is willing to have a client, but it doesn't have one yet.

[Magnus Stattin]

I think that what you can call when on the EJBContext is one of the hardest things to understand and remember.
This is my explanation for this:
Activation in both stateful session bean and entity beans is done by the container to link the bean to the EJBObject. In the case of a stateful session bean every client has its own EJBObject. That is the reason why client security information is available.
In a the case of an entity bean the EJBObject is not specific to any client so the client security information will not be available. The container may choose to keep the bean linked to the EJBObject (Commit option B) all the time and the container's call to activate may not be related in time to when the client calls the business method.
I'm not sure this made any clearer and it is not to say that it's a better explanation than Reid's. If anyone has an easier explanation it would be nice to know.
/Best Regards
Magnus

[Sudhir V]

This discussion brings another question in mind and this may sound stupid: In entity beans, since many clients can be connected thru the same EJBObject how does the container know which client is invoking the method. If it does'nt know then how can it pass client security info to the bean instance?

[Yi Meng]

Originally posted by Sudhir Sudhir:
This discussion brings another question in mind and this may sound stupid: In entity beans, since many clients can be connected thru the same EJBObject how does the container know which client is invoking the method. If it does'nt know then how can it pass client security info to the bean instance?

many clients can be connected to the same entity bean but thru different EJBObject

[Keith Rosenfield]

Hey Sudhir:

Originally posted by Sudhir Sudhir:
In entity beans, since many clients can be connected thru the same EJBObject how does the container know which client is invoking the method. If it does'nt know then how can it pass client security info to the bean instance?

The container actually should know which client is invoking the method. Remember that the container intercepts all client calls and can make the determination then.

[Magnus Stattin]

According to Head First EJB (Page 99) the clients do share the EJBObject for a particular entity bean. If this is not the case, please correct me.
Sudhir Sudhir's question on how the client security information is propagated to the entity bean is very interesting. How does the principal and role of the client get propagated with a client call?
/Magnus

[Keith Rosenfield]

Hi Magnus:

Originally posted by Magnus Stattin:
According to Head First EJB (Page 99) the clients do share the EJBObject for a particular entity bean. If this is not the case, please correct me.

This is correct.

Originally posted by Magnus Stattin:
How does the principal and role of the client get propagated with a client call?

I don't think we need to know the mechanism that the container uses to propagate a client security context for the exam, although we do need to know in which methods we have access to it.

[Magnus Stattin]

The reason I think it is important is that it might help explain why client security information is available sometimes and sometimes not. Is it stored in the EJBObject or is it stored in the stub?
I'm interested in really understand why things are like they are and not just memorize it.
/Magnus
[ January 16, 2004: Message edited by: Magnus Stattin ]

[Sudhir V]

I agree with Magnus. I started this thread with a question "Why cannot we access client security information in the entity bean's ejbActivate method". Reid's answer was correct becuase the HFE does say that client is not associated during ejbPassivate so during ejbActivate also its not associated with a client.
Coming to my second question "How does container know which client has invoked the method (in case of multiple client accessing the same EJBObject)". The only solution seems EJBObject tracks the different clients and the container has access to this information. Am I going in the right direction............