Invalidation of an existing session

Is there anyway to retrieve the session object if we know the sessionId ?

I am trying a customized implementation of single-sign-out - if a user logs out of one application he should be logged out of another application as well. I do retain the sessionId of the parent application. Using this value, i would need to invalidate the existing session. Is there anyway i could do this.

Subramanian Narayanaswamy wrote:Is there anyway to retrieve the session object if we know the sessionId ?

Directly, No. SUN has deprecated the API for the same.

But with little hack you can do this:
Create a application scoped map for Session Id(key) and session object(value), Add the key-value pairs for each new session-id and invalidate the session (value) if the users wished to sign out.

Thanks for the response. Thats what i was trying as a work around.

Guess a readymade API would have really helped here.

Subramanian Narayanaswamy wrote:Thanks for the response. Thats what i was trying as a work around.

Where do you store the map.

Lets say, you have
1. SSO application
2. Application 1
3. Application 2

If all the request are passed through SSO then abevioulsy it will be SSO application.
But how do you get the the session object for each user session to the sso application to store.

Subramanian Narayanaswamy wrote:
Guess a readymade API would have really helped here.

Do you really think to implement above steps one need a readymade API ?

Sagar Rohankar wrote:

Subramanian Narayanaswamy wrote:
Guess a readymade API would have really helped here.

Do you really think to implement above steps one need a readymade API ?

+1

Mohamed Inayath wrote:
But how do you get the the session object for each user session to the sso application to store.

Once the user logs in, we retrieve its attached session object with id and stores into a map.

Sagar Rohankar wrote:
Once the user logs in, we retrieve its attached session object with id and stores into a map.

You are right.

My question was where will you store the session objects in one common store map.

In a SSO envoironment there will be having different application with different context. Am I right in saying this.
So all your request will be passed thru SSO.
Accordinly one will be having multiple conexts (SSO, APP1, APP2..APPn).

My question is where you are going to keep your store map?

Is it in SSO, APP1, APP2..APPn..

Most possibly in SSO application and we can have access to cross context variables(Don't have any knowledge about cross context access, but I heard somewhere that we can do this, Consult Google OR search same forum)

Sagar Rohankar wrote:Most possibly in SSO application and we can have access to cross context variables(Don't have any knowledge about cross context access, but I heard somewhere that we can do this, Consult Google OR search same forum)

Sorry, You cannot do that..

Context can't be shared.

I told you, I heard it somewhere and need a search, Until when I Googled, I found this and this.

Is it really what we are looking for ?

Sagar Rohankar wrote:I told you, I heard it somewhere and need a search, Until when I Googled, I found this and this.

Yes,.. Memory In replication is Clustering service replicates the session data between the two JVMs but what we are looking into is quite different.
The Clustering services takes care of the replication of session objects.

Is it really what we are looking for ?

Actually we are diverting the actual topic.
Its better we can try to solve the actual issue.

Anyways thanks for the links its quite useful one

Ok, I got it now, its not that much easy as I supposed previously. After searching this forum for the same issue I come across this thread. Hope it might helps.