OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ws-sx-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: WS-Trust WSDL that supports negotiation and challenge

We have run into a problem when trying to define a WSDL for WS-Trust 1.4
that can support the negotiation and challenge extensions and would
welcome any advice in this area.

Our STS implements parts of the WS-Trust 1.4 issuance binding but also
needs to support the <wst:BinaryExchange> to return challenges.  As a
result, depending on the type of RST sent, the STS may need to return
one or more RSTRs with a challenge before returning the final RSTRC with
the requested token.  The exchange pattern is then RST -> [RSTR ->
RSTR]*-> RSTRC where a pair of RSTRs are exchanged for each challenge
stage before the final RSTRC containing the tokens is returned by the

The issue we have run into is that we need to allow the STS to return
different responses to the RST depending on whether or not it needs to
challenge the client but have not been able to create a WSDL that
supports this; it does not appear to be possible to have more than one
output type from an operation. Are there any recommendations on how a
WSDL be defined for WS-Trust that supports the different types of
responses?  Even the one in Appendix B of WS-Trust does not appear to do

For example, the <wsdl:portType> for the issue binding could be defined
as follows:

    <wsdl:operation name="Issue">

This will work fine when an RSTRC is returned in response to the RST
sent by the client but will not work when the STS needs to issue a
challenge and so needs to return an RSTR.  This would instead require an
operation of the following form:

    <wsdl:operation name="Issue2">



The problem is that we have to define separate <wsdl:operation> elements
for each input/output pair, it is not possible to have one that can
return both an RSTR and an RSTRC.  This means that when we come to
define the <wsdl:binding> we need to define different operations for
each possible exchange type.

If a client ignores the WSDL and just inspects the SOAP body then it can
handle the different return types.  For example, it could use the
<wsa:Action> header to discriminate.  But if a client is generate from
such a WSDL then it will have different methods for each of the above
operations and would need call the method that has the appropriate
response.  It would, in effect, need to be able to anticipate what the
response should be.

Thanks a lot

Gareth Richards

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]