Hi- I am working on an STS implementation. I would like to emphasize token transformation, as that seems to be the most compelling value proposition in WS-Trust. The Issue operation defines a token transformation from the SupportingToken specified in the SecurityPolicy binding, to the TokenType/KeyType specified in the invocation. I was hoping to use the Validate operation as a more flexible token transformation invocation, leveraging the variant where the TokenType is something other than /RSTR/Status. In such a scheme, the TransportBinding could protect a Validate invocation which could support multiple transformations, a more flexible deployment model than protecting the Issue operation with a single SecurityPolicy binding.
However, I noticed that in both the 2.7.8 and 3.0.3 code base, the AbstractSTSClient does not write the KeyType in a Validate invocation, and writes the KeyType only in an Issue operation. Without the KeyType, a robust set of output token types cannot be defined. I’m wondering if I am attempting to push WS-Trust beyond its intended uses - i.e. that token transformation is best modeled by multiple STS instances, each supporting the Issue operation, and each supporting a single SecurityPolicy binding corresponding to one of the input token transformation types. In other words, I’m wondering if the lack of a KeyType specification in the Validate invocation is not a bug/oversight, but rather a concession to the convention dictating WS-Trust consumption. Thoughts? Thanks Dirk -- View this message in context: http://cxf.547215.n5.nabble.com/STS-Validate-Operation-and-token-transformation-tp5753327.html Sent from the cxf-user mailing list archive at Nabble.com.
