| Author |
Message
|
| john01 |
 Posted: Wed Jun 16, 2010 12:46 pm Post subject: SOAP SSL authentication |
 |
|
Novice
Joined: 16 Jun 2010
Posts: 21
Location: PT
|
Hi,
I am using WMB 7.0.
I have a web service implemented with SOAP nodes that use SSL authentication with certificates.
For each client I have a different certificate installed, the SSL authentication mechanism picks the right certificate each time a client connects.
The Web Service is working like it should.
However, after the SOAPInput node, I would like to know which certificate was used in each client SSL authentication.
My aim is to verify that the client identification in the message matches with the corresponding certificate, preventing possible client impersonations.
Thanks in advance. |
|
| Back to top |
|
 |
| smdavies99 |
| Posted: Wed Jun 16, 2010 9:08 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
You've already done that by using different certificates. That is the whole idea of two part keys. You give one party half. You keep the other.
Once the key exchange has taken place, you have a trusted connection.
I suppose you could do something with WebServices Security but I'm know sure.
It just sounds to me like you are being overly cautious.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| john01 |
| Posted: Thu Jun 17, 2010 1:53 am Post subject: |
|
|
Novice
Joined: 16 Jun 2010
Posts: 21
Location: PT
|
Here is an example of the issue:
Imagine that a client A connects to the web service successfully. Now he is authenticated by SSL layer, but (here is the problem) he can send a request on behalf of a Client B.
If I don’t check that client mentioned inside the request (e.g. client A) is the same of the authentication time (e.g. cert A) I have a problem... |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Jun 17, 2010 6:07 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| john01 wrote: |
| but (here is the problem) he can send a request on behalf of a Client B. |
How? You know he's Client A (because you've authenticated him). He might be able to send a request on behalf of Client B but only because your system is allowing that. He can't impersonate Client B, which is the point.
If A is not allowed to send requests on behalf of B (or anyone else) prevent that.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Thu Jun 17, 2010 6:15 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
Here's my take on the problem
Both A & B have their own keys allowing them to connect to the same service
Inside the Flow, how can the flow validate that the request is really from B and not A impersonating B.
IMHO, there are TWO possible ways to solve this.
1) Create TWO different Services and only give one name to A & B. Make each service contract(WSDL) sloghtly different. Then if they impersonate the other user they will use their own contract data thus causing a SOAP fault.
OR (I'm not sure here)
Look at the HTTP Header in the message. This should contain the sender url.
This can be validated in the flow. AFAIK (And I've not really looked) there is a Transport header as well as the SOAP header in the message folders.
I'm sure others with a greater understanding here will correct me if I'm wrong (most likely)
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| john01 |
| Posted: Thu Jun 17, 2010 7:02 am Post subject: |
|
|
Novice
Joined: 16 Jun 2010
Posts: 21
Location: PT
|
| Vitor wrote: |
If A is not allowed to send requests on behalf of B (or anyone else) prevent that. |
Actually, that is what I'm trying to achieve.
| smdavies99 wrote: |
Both A & B have their own keys allowing them to connect to the same service
Inside the Flow, how can the flow validate that the request is really from B and not A impersonating B.
|
Exactly, that's correct.
| smdavies99 wrote: |
IMHO, there are TWO possible ways to solve this.
1) Create TWO different Services and only give one name to A & B. Make each service contract(WSDL) sloghtly different. Then if they impersonate the other user they will use their own contract data thus causing a SOAP fault.
|
That could be a solution, but I have too many clients using the same service.
| smdavies99 wrote: |
OR (I'm not sure here)
Look at the HTTP Header in the message. This should contain the sender url.
This can be validated in the flow. AFAIK (And I've not really looked) there is a Transport header as well as the SOAP header in the message folders.
I'm sure others with a greater understanding here will correct me if I'm wrong (most likely) |
I've looked up inside all message folders for something related with client information and I've found nothing. But maybe exists some other folder... Can anyone please tell me which folder should I look for?
Or suggest another way of solving this problem.
Thanks! |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Jun 17, 2010 9:28 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
So your setup doesn't authenticate a given user, just that he's a member of an authorised group of users who have been given the correct key for the service? So when you said:
| Quote: |
| Imagine that a client A connects to the web service successfully. Now he is authenticated by SSL layer |
in actuallity he is not authenticated. Someone has been authenticated but you can't tell who.
Do I have the proverbial stick by the right end here?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Jun 17, 2010 10:02 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
|
| Back to top |
|
|
| john01 |
| Posted: Thu Jun 17, 2010 10:03 am Post subject: |
|
|
Novice
Joined: 16 Jun 2010
Posts: 21
Location: PT
|
| Vitor wrote: |
So your setup doesn't authenticate a given user, just that he's a member of an authorised group of users who have been given the correct key for the service? So when you said:
| Quote: |
| Imagine that a client A connects to the web service successfully. Now he is authenticated by SSL layer |
in actuallity he is not authenticated. Someone has been authenticated but you can't tell who.
Do I have the proverbial stick by the right end here? |
In fact the client is authorized by the SSL layer but inside the flow I don't know who he is.
I should not trust the message composed by the client, it might just tell me it's from somebody else, I've no way of confirming.
But if I knew which public key the SSL layer used in the authentication, then I could verify. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Jun 17, 2010 12:55 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Require the clients to sign their request with their private key.
You can then verify the signature with the client's public key.
Whichever matches is the client sending the request... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| john01 |
| Posted: Mon Jun 21, 2010 9:04 am Post subject: |
|
|
Novice
Joined: 16 Jun 2010
Posts: 21
Location: PT
|
Well, as far as I understood seems that WS-Security is more useful than SSL in this situation.
Will there be a performance decrease but ok there's no other way around, right?
Thanks for all the comments btw. |
|
| Back to top |
|
|
|
|
