Webservices and "pass through" security

[Tom]

Hi,

I am currently on a project where one site needs to send the user
credentials to another site, through web services.

Scenario:

* "User 1" will authenticate to "Site A" using NTLM ("Site A" provides
front-end presentation of data)
* "Site A" will request confidential information about "User 1" to "Site B"
("Site B" has a database of confidential data for each user), via web
service call

The developers of "Site B" are worried about "Site A" sending the wrong
credentials (i.e. wrong NT login ID), meaning that the visitor of "Site A"
could see someone else data...

How could we resolve this using standard .NET webservices?

How can we garantee to "Site B" that the visitor on "Site A" is really "User
1"?

Also, how can we ensure that only the webservice client from "Site A" can
access the webservice from B? We suggested IP address registration of Site A
servers with "Site B", but the developers think this is not enough.

Many thanks!!
Tom

[BillyLiu007]

yes there is a way of doing it....

i quote this from the WSE2.0(web serivce enhancement) document

Web services can be secured today, but limitations exist when it comes to
building scalable distributed applications based on Web services.
Specifically, it is difficult to build scalable applications that cross
security domains. Today, you can secure Web services by having the message
sent over a secure transport, such as Secure Sockets Layer (SSL), but that
only works when the communication is point-to-point. That is, if the SOAP
message must be routed to one or more intermediaries before reaching the
ultimate receiver and the entire route uses SSL, then the ultimate receiver
still has to communicate with the sender to authenticate the sender of the
SOAP message. That scenario is difficult to scale.

One of the ways WSE helps to build scalable distributed applications is by
providing an efficient and scalable mechanism to secure Web services. It uses
the mechanisms defined in the WS-Security specification to place security
credentials in the SOAP message itself. This is done by having a client
obtain security credentials from a source that is trusted by both the sender
and receiver. When a SOAP message sender sends a SOAP request, those security
credentials, which are generically known as security tokens, are then placed
in the SOAP message.
...............

for full article, please refer here:

http://msdn.microsoft.com/library/de...c5b2f2191d.asp

--
Can You?You Can.
"Tom" wrote:

Hi,

I am currently on a project where one site needs to send the user
credentials to another site, through web services.

Scenario:

* "User 1" will authenticate to "Site A" using NTLM ("Site A" provides
front-end presentation of data)
* "Site A" will request confidential information about "User 1" to "Site B"
("Site B" has a database of confidential data for each user), via web
service call

The developers of "Site B" are worried about "Site A" sending the wrong
credentials (i.e. wrong NT login ID), meaning that the visitor of "Site A"
could see someone else data...

How could we resolve this using standard .NET webservices?

How can we garantee to "Site B" that the visitor on "Site A" is really "User
1"?

Also, how can we ensure that only the webservice client from "Site A" can
access the webservice from B? We suggested IP address registration of Site A
servers with "Site B", but the developers think this is not enough.

Many thanks!!
Tom

[BillyLiu007]

yes there is a way of doing it....

i quote this from the WSE2.0(web serivce enhancement) document

Web services can be secured today, but limitations exist when it comes to
building scalable distributed applications based on Web services.
Specifically, it is difficult to build scalable applications that cross
security domains. Today, you can secure Web services by having the message
sent over a secure transport, such as Secure Sockets Layer (SSL), but that
only works when the communication is point-to-point. That is, if the SOAP
message must be routed to one or more intermediaries before reaching the
ultimate receiver and the entire route uses SSL, then the ultimate receiver
still has to communicate with the sender to authenticate the sender of the
SOAP message. That scenario is difficult to scale.

One of the ways WSE helps to build scalable distributed applications is by
providing an efficient and scalable mechanism to secure Web services. It uses
the mechanisms defined in the WS-Security specification to place security
credentials in the SOAP message itself. This is done by having a client
obtain security credentials from a source that is trusted by both the sender
and receiver. When a SOAP message sender sends a SOAP request, those security
credentials, which are generically known as security tokens, are then placed
in the SOAP message.
...............

for full article, please refer here:

http://msdn.microsoft.com/library/de...c5b2f2191d.asp

--
Can You?You Can.
"Tom" wrote:

Hi,

I am currently on a project where one site needs to send the user
credentials to another site, through web services.

Scenario:

* "User 1" will authenticate to "Site A" using NTLM ("Site A" provides
front-end presentation of data)
* "Site A" will request confidential information about "User 1" to "Site B"
("Site B" has a database of confidential data for each user), via web
service call

The developers of "Site B" are worried about "Site A" sending the wrong
credentials (i.e. wrong NT login ID), meaning that the visitor of "Site A"
could see someone else data...

How could we resolve this using standard .NET webservices?

How can we garantee to "Site B" that the visitor on "Site A" is really "User
1"?

Also, how can we ensure that only the webservice client from "Site A" can
access the webservice from B? We suggested IP address registration of Site A
servers with "Site B", but the developers think this is not enough.

Many thanks!!
Tom