I had a good conversation with Kevin this morning. I agree with him for the following reasons. Currently the STS Action is creating a token (via the STS) but updates the current security context with the new SC. The SC that the action was invoked is lost. Kevin asserts and I agree that the new SAML token should just augment the security context that currently exists rather than switching. If you want to switch the SC, then that should be a configurable option. The STS action should be replaced by a pluggable SAMLTokenIssuingLoginModule such that you can just either push it in a new SecurityAction that does JAAS internally or you need to plugin the LM in the current JAAS framework wherever it is in the ESB infrastructure. Kevin mentioned that the JAAS layer already exists. So the STS action is not a replacement here. On the SAML token validation end, the current LM is fine. But there is a difference of opinion on the token generation end. So you can either use a SecurityAction or use existing JAAS layer to do the following: logincontext.login Now the SAMLTokenIssuingLM will contact the STS for a new token. Then update the JAAS subject with this new token. You can choose either to make it a principal or a credential. Then before anything is sent on the wire to do a WS call, u can pluck the SAML token off of the security context (which has the JAAS subject) and send it over the wire. Kevin, please update the text with clarification or pointers. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261633#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...