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: 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]