-
1. Re: Usage of STSClient
beve Oct 28, 2009 2:41 PM (in response to beve)Actually when I thought some more about this I don't think this will matter for a login module. The login module will always get initialized for each login and creating the WSTrustClient will always be done.
-
2. Re: Usage of STSClient
anil.saldhana Oct 29, 2009 4:36 PM (in response to beve)An STSClient is created for each play by the LM. The STSClient cannot cache a different username/cred than what the LM is dealing with.
The STSClient will be an internal implementation detail of the LM. So it should use whatever the ctx the LM gives it. -
3. Re: Usage of STSClient
beve Oct 29, 2009 4:53 PM (in response to beve)An STSClient is created for each play by the LM. The STSClient cannot cache a different username/cred than what the LM is dealing with.
Got it now. Thanks
What I'm not sure about is the username and password usage. Let me explain my use case.
I have two login modules, STSIssuingLoginModule and STSValidatingLoginModule.
Currently the STSIssuingLoginModule expects the username/password to be provided by either by the calllbackhandler or by a previous LM (in which case the LMs would be using the 'password-stacking' option).
Now this principal will become the subjectName of the Subject of the issued Assertion if I understand this correctly?
The STSValidatingLoginModule expects the username/password to be configured as an option in the LM configurtion. Default is to have this in a properties file. The reason for this to not be handled in the same way as is done for the STSIssuingLoginModule is that this username/password is only used to authenticate with the STS and not used in the validation process. The actual the actual validation is done using the digital signature of the security token.
Do you agree with what I'm saying here and this approach ?
Thanks,
/Daniel -
4. Re: Usage of STSClient
anil.saldhana Oct 30, 2009 4:26 PM (in response to beve)Dan, let me just comment on the STS validation process. The STS needs to validate a token (that was provided to it) based on the configured policy. The policy can be to validate based on signature alone or validate the subject identifiers in addition to signature or just the subject identifier. Or the validation can be based on a custom policy.
We started with the simplest case of validating the signatures. It should be possible to plug and plug different validation logic. That is what a real world STS will look like. As our needs/feedback cycles evolve, we can look at different validation providers. You may want to contribute your own providers to the JBID project based on ESB needs. -
5. Re: Usage of STSClient
beve Nov 4, 2009 1:56 AM (in response to beve)Hi Anil,
We started with the simplest case of validating the signatures. It should be possible to plug and plug different validation logic. That is what a real world STS will look like. As our needs/feedback cycles evolve, we can look at different validation providers.
Ah, I got it now. I've made some changes to the code to reflect this.
Thanks,
/Dan