JBossDeveloper

"beve" wrote:
Just to avoid any confusion that here.... The validation is only performed through the JBossSTSLoginModule which is a JAAS Login module.
And the JBossSTSAction only performs issue request to JBossSTS and does not have methods for validating a security token.

Sorry if this was already understood.

/Dan

"anil.saldhana@jboss.com" wrote:
I think that strategy is correct.

"anil.saldhana@jboss.com" wrote:
Validation has to happen through pluggable login modules. Toward this, the STS login module seems appropriate.

"anil.saldhana@jboss.com" wrote:
When the ESB layer has to generate SAML tokens, it needs to contact the STS. Hence it needs some integration logic (satisfied by the STS Action).

"anil.saldhana@jboss.com" wrote:
I am assuming that the token generation happens before the ESB layer is called. Once an entity gets hold of the token, the ESB call is made with the token. Now on the ESB side, the login module is fielded to validate.

Maybe let us discuss by use case here. (sorry if these two use cases are obvious). ;-)

we have two scenarios here:

1. client didn't have a saml token, it just has username&password, and it tries to use our SAML Login Module to do the authentication. In this case, our LoingModuleImpl should have two steps.
1). Use the username&password to issue a token.
2). Validate this token and propagate this token if necessary.

2. client had an existing saml token. It expects ESB to do the authentication based on this token. Our LoginModuleImpl just need one step.
1) Validate this token and propagate this token if necessary.

Based on above analysis, I thought the LoginModule should be only doing one thing, and also issue a token should not belong to the LoginModuleImpl. (it should be happened before talk to JAAS authentication, just like you should have username&password, and then try to talk to JAAS).

So I prefer to have an action and a LoginModule instead of having just one LoginModule.

Sorry if I misunderstood something here. ;-)

Regards
Jeff

"jeff.yuchang" wrote:
So I prefer to have an action and a LoginModule instead of having just one LoginModule.

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.

Kevin mentioned that there is precedence in using JAAS for login. Not sure where that is. Since the STSAction was just getting a token, I feel that it should be replaced by a generic Security Action that internally does JAAS login.

So you can plugin login modules there to get the desired token. Or you can circumvent a call from going further if an user desires.

So either a generic SecurityAction (or call it JAASAction) or reuse any JAAS framework that exists around the region where STSAction was supposed to get into play.

We already handle JAAS login as part of the security on the service, which is the level at which we are enforcing security credentials. There is no need for a separate action.

What should happen, though, is that this functionality should be moved out to a LoginModule and that these should really be part of the identity framework (wither directly or as an extension) so that they can be used in other areas.

At present we are providing the LoginModule as part of our codebase and this does not seem right.

Kev