5 Replies Latest reply on Nov 4, 2009 1:56 AM by beve

    Usage of STSClient

    beve

      Hi,

      I've been wondering about one thing with regard to the WSTrustClient. When an instance of this class is created a username and password is used.
      I have a LoginModule (LM) that is used only for validating tokens and I only create a single instance of the STSClient. In this case the username and password is of a user that is allowed to validate tokens. Is it correct that validation will be performed with out regard to the passed in user and that the username/password is only used for authentication with JBossSTS? My understanding is that the actual validation is done using the digital signature of the security token.

      Now, I also have the need for a different LM, but this one will be used for issuing tokens. The LM would use the callbackhandler configured to get back a username and password. This username/password combination would then be used to issue a token for that user.
      For this I would need to create a new STSClient for every issue request as I need to specify the username and password. Is this the correct usage or is there another way of doing this?
      My concern is really just with performance as I suspect creating a dispatch object would be somewhat heavy.

      Thanks,

      /Daniel

        • 1. Re: Usage of STSClient
          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

            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

               

              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

                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

                  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