[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Antwort: WS-Trust, differentiation of validate and issue binding
<img src="http://zdownload.zurich.com/mailimages/ZHP_MailHeader.gif" /> Hi guys Does anybody have any feedback to my comment? I'd highly appreciate it. Regards Oliver Wulff Oliver Wulff/CHK/Externa l/Zurich An ws-sx-comment@lists.oasis-open.org 28.10.2010 11:24 Kopie Thema WS-Trust, differentiation of validate and issue binding Hi there I've got a question to a statement in the validate binding: >>> This binding assumes that the validation requestor and provider are known to each other and that the general issuance parameters beyond requesting a token type, which is OPTIONAL, are not needed (note that other bindings and profiles could define different semantics). >>> Does this mean that when the requestor requires a security token transformation he must not pass the elements like Claims, KeyType, etc.? I think I have to pass the KeyType Bearer because otherwise it's implicitly assumed by the STS that the default KeyType (Symmetric) is requested when a token transformation from ? to SAML is requested. I think it's quite difficult to figure out where the differentiation is between the issue and validate binding. It's very clear for the client application that it issues a security token and passes this to the server. The server sends a validate to the STS because he can't verify the security token. The validate binding allows to return (or issue) a new security token which is understood by the service provider side. The question is a security token has to be passed for the validate and issue binding and in both cases a security token can be returned (or issued). But where is the difference? An example: A service consumer sends a SAML token to a service provicer. The service provides sends a validate request to the STS including the SAML token but requests a kerberos token (let's assume KDC and STS are trusted). The kerberos token is returned to the service provider. Now, from a kerberos point of view, a kerberos token is issued but from a WS-Trust point of view a security token transformation happened. One other example: A service consumer sends a UsernameToken to a service provider. The service provider sends a validate request to the STS including the UsernameToken but requests a saml token. It should be opaque to a service provider which security token it is. If he doesn't understand the token he sends it to the STS for validation and maybe asks to get another token back. But is this really a validate request to the STS or an issue request OnBehalfOf? I'd prefer to look at the UsernameToken as a security token like any other to keep it opaque for the service provider. OK, you could argue that a web service consumer should sent a token which is understood by the service provider based on the WS-SecurityPolicy of the service provider. But, in big companies you will always have systems which support only some basic security functionality like sending UsernameToken and don't have the STS client functionality available. Therefore, the service provider can't assume that a security token is sent which he can verify. Thank you and regards Oliver ******************* BITTE BEACHTEN ******************* Diese Nachricht (wie auch allfällige Anhänge dazu) beinhaltet möglicherweise vertrauliche oder gesetzlich geschützte Daten oder Informationen. Zum Empfang derselben ist (sind) ausschliesslich die genannte(n) Person(en) bestimmt. Falls Sie diese Nachricht irrtümlicherweise erreicht hat, sind Sie höflich gebeten, diese unter Ausschluss jeder Reproduktion zu zerstören und die absendende Person umgehend zu benachrichtigen. Vielen Dank für Ihre Hilfe. ******************* BITTE BEACHTEN ******************* Diese Nachricht (wie auch allfällige Anhänge dazu) beinhaltet möglicherweise vertrauliche oder gesetzlich geschützte Daten oder Informationen. Zum Empfang derselben ist (sind) ausschliesslich die genannte(n) Person(en) bestimmt. Falls Sie diese Nachricht irrtümlicherweise erreicht hat, sind Sie höflich gebeten, diese unter Ausschluss jeder Reproduktion zu zerstören und die absendende Person umgehend zu benachrichtigen. Vielen Dank für Ihre Hilfe.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]