aspose file tools*
The moose likes EJB Certification (SCBCD/OCPJBCD) and the fly likes Accessing Security Info in ejbActivate() Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » EJB Certification (SCBCD/OCPJBCD)
Bookmark "Accessing Security Info in ejbActivate()" Watch "Accessing Security Info in ejbActivate()" New topic
Author

Accessing Security Info in ejbActivate()

Rahul Mishra
Ranch Hand

Joined: Jan 22, 2006
Posts: 211
Why don't the ejbActivate()/ejbPassivate methods in Entity Beans have an access to Security Information of the client?


A Logical answer here will be appreciated...


OCMJEA/SCEA, SCDJWS, SCBCD 1.3, SCJP 1.4
My SCEA experience:http://javalogue.blogspot.com/
Frederic Esnault
Ranch Hand

Joined: Feb 13, 2006
Posts: 284
Hi Rahul,

this is simple. Entity beans are passivated when the container wants to dissociate the entity object from the database entity. When this happens, the entity bean is not linked to an entity anymore, and logically cannot serve a client anymore => the client does not have access to this EB. From the EB point of view, it has no more client (and no more entity), so it's not possible to access the client security info.

When the EB is activated, the container calls this method to tell the bean it's begin activated, before it calls the loading callback (ejbLoad). This is a kind of initialization method, the EB does not belongs to a client yet. After data has been loaded, the EB is available for client calls, and so can access its security information.

Hope I was clear.


SCJP 5 - SCWCD 1.4 - SCBCD 1.3 - Certification study documents/resources: http://esnault.frederic.free.fr/certification
Ankit Doshi
Ranch Hand

Joined: Dec 04, 2002
Posts: 222
Hi Frederic,

Your explanation about ejbActivate is quite logical, but then how does the client security info is available in ejbLoad?

I thought container calls ejbLoad immediately after loading data (to allow bean to decrypt or do such operations on data) and immediately before passing the client invocation of business method to bean.

The sequence diagram displayed on page 352 of HFEJB also indicates that the container calls ejbActivate, then calls ejbLoad, and then only the client invocation of the business method gets passed onto the bean. So going by this logic, the client security info should also not be available in ejbLoad as well, isn't it?
Frederic Esnault
Ranch Hand

Joined: Feb 13, 2006
Posts: 284
Hi,

you're making a mistake. You must not think that ejbLoad is called only after an acivation (and ejbStore for a passivation). ejbLoad may be called at any time, whenever the container thinks it needs to update data.

The spec even states that the ejbLoad mehtod is called immediatly after the data has been loaded, and that the bean provider should use this method to initialize bean state with values depending on data.

The thing is some initialization/re-initializations of bean state may depend on client identity/role, and so bean may need to access caller security info.

Is it clearer?
[ April 13, 2006: Message edited by: Frederic Esnault ]
Ankit Doshi
Ranch Hand

Joined: Dec 04, 2002
Posts: 222
Well, it looks good ... but I am quite confused about exactly when does the bean instance gets a client context and/or a transaction context etc.

This confusion is not only with this scenario, but with whole lot of permutation combinations of the different types of beans, different methods etc.

Do you have a document on your website that can help understand the various "Bean things you can do/access..." with various types of beans / frin within various methods?
Frederic Esnault
Ranch Hand

Joined: Feb 13, 2006
Posts: 284
You ask just a little bit too early, I'm actually currently working on the document you describe

It should be available tomorrow I hope. I'll post here as soon as it's done.
Ankit Doshi
Ranch Hand

Joined: Dec 04, 2002
Posts: 222
Oh that'll be great!!! Thanks a ton...
Frederic Esnault
Ranch Hand

Joined: Feb 13, 2006
Posts: 284
Hi !

As I promised I published this document today on my website.
Please excuse me for the delay, but I had to repaint my living room or my wife would have killed me

Comments are more than welcome about the document. I tried to make a clear concept, using contexts and associating them to allowed operations. It's quite clear to me, but maybe not to you.

Anyway, any comment is welcome.
Ankit Doshi
Ranch Hand

Joined: Dec 04, 2002
Posts: 222
Frederic and others,

Still a bit confused, specifically about the ejbActivate...

What I was thinking was like this - the ejbActivate would only be called on a bean when 1) bean is passivated AND 2) client invokes a business method on the bean. Is this correct?

In other words, if we can safely assume that container will call ejbActivate as part of the client invocation of business method only (just like we assume for the ejbCreate method of the SFSB), then we should be able to get the client security info in ejbActivate ... what do you say?
Frederic Esnault
Ranch Hand

Joined: Feb 13, 2006
Posts: 284
No because there is a huge difference between sfsb and eb.

When a sfsb is passivated, it still belongs to its client. Its conversational state is "serialized", and the bean goes to secondary store, not consuming resources anymore. When the client invokes a business method on it, the bean is re-activated and immediately belongs to its client. There is not one second where the bean has no client. That's why in the ejbActivate method, the bean knows its client, and so may access client security.

For entity beans, the passivation thing is not the same. A passivated entity bean is separated from its client, and from its entity (data in DB): it becomes an empty "entity bean skeleton". At this point, there is no client anymore for the bean instance. When a client needs an entity bean, the container may choose this specific instance (or another), activate it (calling ejbActivate()), then it loads data from database to fill the entity instance, and finally calls ejbLoad() to tell the bean it has been loaded with data. At this point, the bean is loaded and has its client. From the ejbLoad() method on, you may access client security information.

Is it clearer?
Ankit Doshi
Ranch Hand

Joined: Dec 04, 2002
Posts: 222
Well,

- The ejbCreate in SFSB is executed ONLY BECAUSE client is requesting something on the bean ... since client is requesting something here, so client is available, and therefore client security info is available in ejbCreate
- The ejbActivate in EB is executed ONLY WHEN the client wants a business method to be executed ... since client is requesting a business method, so client is available here as well ...

What is the difference here? In both the cases, client is requesting something to the bean, so the client is there in both the cases.

I agree what you are saying:
A passivated entity bean is separated from its client, and from its entity


Though the bean instance would not be linked to it's DB entity during ejbActivate, but the client is there.

The very fact that the ejbActivate method is being executed, means there is a client out there who is asking some business method to be executed, and to complete this client request, the container is calling the ejbActivate method (as part of the container services). Moreover, the bean instance on which the ejbActivate is being called by container, this is the instance which is ultimately going to serve this client.

So when the client is there, then what is the reason for disallowing to get client security information?
Ankit Doshi
Ranch Hand

Joined: Dec 04, 2002
Posts: 222
Adding to the above post:

The passivated EB is not associated with a specific client. But when the entity is being activated (through ejbActivate) it is no more passivated, rather, it is in the process of getting ready to serve the business method for the client.
Frederic Esnault
Ranch Hand

Joined: Feb 13, 2006
Posts: 284
You almost answered your question yourself.

When ejbActivate is called, the entity bean is in the process of getting ready to serve. But at this time, its data is still not loaded, and so it's not ready for client service. In the ejbLoad method, data has been loaded, so the entitybean is up and ready for service.

You could think of the state the bean is in when ejbActivate is called as a kind of corrupted state (meaning its data is not what it should be yet, because it has not been loaded), so the link between the bean and the client is not made.

Better now?
Ankit Doshi
Ranch Hand

Joined: Dec 04, 2002
Posts: 222
Probably I was thinking flat, that there is not a direct relationship between "bean being ready to serve client" and "getting the security info while in the process of getting ready" ...

But logically thinking it looks like even if the container allwed to get the caller info in ejbActivate, the bean would not be able to make much use of it, at that point of time ...

so I'll go with what you explained ...

Thanks for your (extended) help ...
Frederic Esnault
Ranch Hand

Joined: Feb 13, 2006
Posts: 284
Don't take my word as holy word, I'm always opened to debate, but in this case, I really think it's logical to delay access to client security info until a time where entity bean is loaded with fresh up-to-date data.

As for the afterCompletion method of stateful session beans where you refuse access to resources and EJBs, because it's possible that a roolback happened and may be bean state is corrupted.

I agree that in the afterCompletion method, this is more obvious, because corrupted state with access to DB or EJBs could lead to a propagation of corrupted state. For entity beans, it may not be so dangerous, but the same principle should be used, and don't link a client to a corrupted bean (ie. not yet loaded with fresh data).

If you don't agree with me, or don't understand my point, just tell me, I'd be glad to discuss.
Ankit Doshi
Ranch Hand

Joined: Dec 04, 2002
Posts: 222
Well, as I said, when the bean is getting ready to serve a client (and is not completely ready), at that time if the container allowed the bean to get the client info how would it matter? I think it's not going to harm anything if it was allowed ... Can it damage/corrupt bean data or state? Don't think so ...

The only logical reason for not allowing this seems like, getting the client info at this stage, when the bean is not completely ready, is not going to help much to the bean ...
Frederic Esnault
Ranch Hand

Joined: Feb 13, 2006
Posts: 284
That was my point. For the afterCompletion method, I agree this is obvious that allowing access to resources or EJBs may lead to propagation of a corrupted state.

But for entity beans, this is true that the direct consequences of allowing access to client info is not clear. But think about it. If a part of entity in DB is the actually the role allowed to do something, and this data is not read at the time client security info is called (in ejbActivate, if we allowed this method to access it): this could lead to allowing a client with an unallowed role to do some modifications. Why? Because the role allowed to do so is part of DB, and so is not read in DB before the ejbLoad method is called. So in the ejbActivate method, you cannot know what data you'll get about this, and so if you'll be able to restrict access as you would expect.

I agree this is quite a deep thought, but the thing is : if you can come up with a scenario where it would not be secure to allow access to client security info, then you should not allow access to it, because it is possible that one day it leads to a system failure.
Ankit Doshi
Ranch Hand

Joined: Dec 04, 2002
Posts: 222
Got it ... that's correct ...
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Accessing Security Info in ejbActivate()