Thanks Sohil. Thats was very helpful indeed. On a less critical note and as tech discussion: Once a person has logged in VIA SSO, I assume JBoss SSO design creates a session on the SSO server. So that for a "Passprt" like token functionality; when a person clicks a link on the browser (say) and moves to another application, one cannot pass credentials. There would be some sort of a session cookie passed on with an encrypted key ..or some similar mechanism. Now, the point being that if the 4th App needs to get some info from the SSO service (like users phone number)*; it can pass the key, thus not compromising on the actual user credentials. Hence that key reference would be maintained on an SSO session. *why would an SSO return phone number? Ans) Because one of the ideas of SSO is also maintain common credential data which may include additional fields. In that scenario a service may request for additonal info. Now this part would not be out of the of box, thats ok. But the rest of the discussion is valid. The issue that kicks in is that SSO sessiosn and local sessions may be out of synch. And thats ok, coz if my SSO session times out in 30 minuts. I may not want o enfore that on the session of a local application which may have its setting for 3 hours. If the person needs to move to another site, then sure he wil require re authentication. This is how some SSO get the job done. So thats what I was referring to as "SSO Session". But I really appreciate the response, it has me excited to dig through the code. :) ...As for the Valve. I saw the code; but Valves connect to the container (engine, host, context), while filters to servlets. Anyway, can always tweak that code basedon our requirement. Thanks! What I really am happy about is I dont need to JBossSX at this phase to complicate my life :) Thanks again. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4122917#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...