SOAP question

[Jacky Chow]

Hi,
The following text is copyed from SOAP 1.1
--------------------------------------------------------------------------SOAP provides a flexible mechanism for extending a message in a decentralized and modular way without prior knowledge between the communicating parties. Typical examples of extensions that can be implemented as header entries are authentication, transaction management, payment etc.
--------------------------------------------------------------------------
How a recipient know a header entry is for authentication, transaction management, or for other purpose if it do not have any prior knowledge of the message sender ?

[Tong Chen]

When get a SOAP request, the RECEIVER will pre-view the SOAP header entries first, if the endpoint needs the authentication info (username/password) to get in, then the RECEIVER will find the authentication info in the header, if can't find it then it will not continue to process the request and send fault info back to the original SOAP SENDER.

[Richard Monson-Haefel]

Tong is right ... but there is a more general point that I think the spec is getting at:
When a node receives a SOAP message its free to ignore any header blocks that it does not recognize, so you can put any headers you want to in the SOAP message; if the node understands them it will process them otherwise they will be ignored.
If, however, the mustUnderstand attribute is 'true' or '1', then the node must generate a fault if it identifies itself with the URL in the actor attribute.
Remember if there is no actor attribute specified than the header block is assumed to be the responsibility of the ultimate receiver.
Also remember that the default value of the mustUnderstand attribute is 'false' or '0', which means that even if the node identifies itself with the URL of actor, it's not required to understand the header block or generate a fault if the header block is not understood.
I hope that helps,
Richard

[Jacky Chow]

Originally posted by Tong Chen:
When get a SOAP request, the RECEIVER will pre-view the SOAP header entries first, if the endpoint needs the authentication info (username/password) to get in, then the RECEIVER will find the authentication info in the header, if can't find it then it will not continue to process the request and send fault info back to the original SOAP SENDER.

So, is that the receiver just GUESS how the SOAP header represents the username/password ?
for example if the receiver expects that a header entry element <username>...</username> to represent the login id, and an other header entry <password>...</password> to represent the login password, but if the message sender do not expect the header entries are used for authentication, then what happen? will that the receiver still use the header entries for authentication ?

[Tong Chen]

Take a JAX-RPC example:
The user name and password passed in the getStockQuoteProvider method are used for authenticating the service client using the HTTP Basic Authentication:
StockQuoteService sqs = // ... Get access to the service
StockQuoteProvider sqp = sqs.getStockQuoteProviderPort("<username>", "<password>");
float quote = sqp.getLastTradePrice("SUNW");
The SENDER may get the service description from the service provider and know the target service endpoint needs username/password to be getting in and the service description MAY need the username/password being included in the request header block.
There are other different ways to send username/password. It depends on how the service provider does the authentication. But including the username/password in the SOAP header block will do the job.

[Jacky Chow]

Thanks Tong, I know how it works now, also thanks to Richard, the extra information you provided are useful!
[ May 12, 2004: Message edited by: Jacky Chow ]

[Sumit Amar]

Is there any example that shows adding authentication information in SOAP headers?

thx

[Jack Zhou]

http://www-106.ibm.com/developerworks/webservices/library/ws-secure/#minorhead4.1