| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| WS-Sec Username Token Digest |
« View previous topic :: View next topic » |
| Author |
Message
|
| goffinf |
 Posted: Mon Feb 04, 2013 6:25 am Post subject: WS-Sec Username Token Digest |
 |
|
Chevalier
Joined: 05 Nov 2005
Posts: 401
|
Version: 8.0.0.1
I'm looking at the WS-Sec support for Authentication and Authorization at a SOAPInput node.
The InfoCentre appears to suggest the for the Username token type that the #PasswordDigest type is NOT supported, can anyone confirm that IS the case ?, i.e. this is not supported :-
| Code: |
<wsse:Security>
<wsse:UsernameToken>
<wsse:Username>user1</wsse:Username>
<wsse:Password Type="...#PasswordDigest">weYI3nXd8LjMNVksCKFV8t3rgHh3Rw==</wsse:Password>
<wsse:Nonce>WScqanjCEAC4mQoBE07sAQ==</wsse:Nonce>
<wsu:Created>2013-01-05T01:24:32Z</wsu:Created>
</wsse:UsernameToken>
</wsse:Security>
|
The InfoCentre states here http://127.0.0.1:1032/help/topic/com.ibm.etools.mft.doc/ac56050_.htm:-
| Quote: |
Compliance with Web Services Security: Username Token Profile 1.1
The following aspects of this specification are supported:
Password types
Text
...
|
so that would appear to be conclusive, i.e. Digest is NOT listed.
To some extent that seems reasonable (in the sense that you would need a way to recover the actual password from somewhere to recreate and compare the hash), but I just want to be sure about that before I look at the X509 and transport encrypted plaintext varieties.
Thanks
Fraser. |
|
| Back to top |
|
 |
| lancelotlinc |
| Posted: Mon Feb 04, 2013 6:29 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
Yes, this is the case if you are not using the Broker security manager, and you can confirm through a PMR. Also, your choice of security providers is quite limited.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| goffinf |
| Posted: Wed Feb 06, 2013 5:37 am Post subject: |
|
|
Chevalier
Joined: 05 Nov 2005
Posts: 401
|
OK, I'm still banging my head against this one. I really do need to be able to support a WS-Security Username token with the password as digest.
I appreciate that the MB docs explicitly state that is not supported, but, I was wondering whether anyone has any other suggestion (I've read a bunch of posts from 'bielesibub' who seems to have covered most eventualities).
I am a bit of a novice in this area !
Some things that are on the table at present :-
1. I can call a web service implemented outside of broker that provides this capability (its implemented in our web service gateway, but is mostly a Java + DB hack which I not sure our internal IT Sec guys are altogether happy about !).
2. Similar to 1 but I do the DB call to retrieve the password and implement the Java in a JCN.
3. LDAP Digest authentication has been suggested. AFAIK this is a challenge response protocol so I'm not sure how that will play out.
4. Just stick with X509 (but some of my internal customers are not happy with that).
5. WS-Sec username token with plain-text password over SSL (or with that header encrypted).
6. TFIM/TAM - no experience of these so not sure whether they are suitable or not here.
Certainly 1 and 2 are not very integrated with the SOAP nodes or PEP and I'm really trying to use an OOTB solution rather than cretae more custom chaos.
I am going to raise a PMR to see if IBM can help, and I'll feed their response back, but would welcome any suggestions ...
Cheers
Fraser. |
|
| Back to top |
|
|
| AndreasMartens |
| Posted: Wed Feb 06, 2013 7:39 am Post subject: |
|
|
Acolyte
Joined: 30 Jan 2006
Posts: 65
Location: Hursley, UK
|
| goffinf wrote: |
| OK, I'm still banging my head against this one. I really do need to be able to support a WS-Security Username token with the password as digest. |
As you've noticed, this is not supported, may I suggest you ask for it to be added?
http://www.ibm.com/developerworks/rfe/?PROD_ID=532
One thing to note, with Digest auth the server *never* sees the full password. The digest itself should be stored and the server compares to that.
| goffinf wrote: |
I appreciate that the MB docs explicitly state that is not supported, but, I was wondering whether anyone has any other suggestion (I've read a bunch of posts from 'bielesibub' who seems to have covered most eventualities).
I am a bit of a novice in this area !
Some things that are on the table at present :-
1. I can call a web service implemented outside of broker that provides this capability (its implemented in our web service gateway, but is mostly a Java + DB hack which I not sure our internal IT Sec guys are altogether happy about !).
|
You'd also have to ensure the link between the gateway and Broker is properly secured (e.g. SSL with a suitably trimmed down truststore)
| goffinf wrote: |
2. Similar to 1 but I do the DB call to retrieve the password and implement the Java in a JCN.
|
This is my favourite of your choices, with the note above; you shouldn't be retrieving the password, but merely retrieving the digest.
| goffinf wrote: |
3. LDAP Digest authentication has been suggested. AFAIK this is a challenge response protocol so I'm not sure how that will play out.
|
We don't currently support this either, but's again it's something that could be considered for addition with a RFE.
| goffinf wrote: |
4. Just stick with X509 (but some of my internal customers are not happy with that).
|
It's what most people go with, it has the additional bonus that it can help against replay attacks if you sign a timestamp+nonce in the ws-security header.
| goffinf wrote: |
5. WS-Sec username token with plain-text password over SSL (or with that header encrypted).
|
This is probably the easiest choice. Make sure you trim down your truststore so it doesn't trust the whole world to initiate SSL channels.
| goffinf wrote: |
6. TFIM/TAM - no experience of these so not sure whether they are suitable or not here.
|
If you disabled security processing in your SOAP Input node, you could use a SecurityPEP node to extract the UsernameToken and paass it to TFIM for it to perform the required verification.
| goffinf wrote: |
Certainly 1 and 2 are not very integrated with the SOAP nodes or PEP and I'm really trying to use an OOTB solution rather than cretae more custom chaos.
I am going to raise a PMR to see if IBM can help, and I'll feed their response back, but would welcome any suggestions ...
Cheers
Fraser. |
Hope you get it all working.
Andreas |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Wed Feb 06, 2013 7:57 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
|
| Back to top |
|
|
| AndreasMartens |
| Posted: Wed Feb 06, 2013 8:00 am Post subject: |
|
|
Acolyte
Joined: 30 Jan 2006
Posts: 65
Location: Hursley, UK
|
I'll pretend I didn't see that! |
|
| Back to top |
|
|
| goffinf |
| Posted: Wed Feb 06, 2013 11:38 am Post subject: |
|
|
Chevalier
Joined: 05 Nov 2005
Posts: 401
|
| AndreasMartens wrote: |
As you've noticed, this is not supported, may I suggest you ask for it to be added?
http://www.ibm.com/developerworks/rfe/?PROD_ID=532
One thing to note, with Digest auth the server *never* sees the full password. The digest itself should be stored and the server compares to that.
|
Yes I'll do that.
| AndreasMartens wrote: |
This is my favourite of your choices, with the note above; you shouldn't be retrieving the password, but merely retrieving the digest.
|
Hmmm you've said that twice now. But the WS-Sec Username token when using a digest password, that digest is generated anew each time by creating a one way hash from the original password, the time stamp and nonce. So I don't see how it can be stored. What am I missing ?
Thanks Andreas. |
|
| Back to top |
|
|
| AndreasMartens |
| Posted: Thu Feb 07, 2013 1:23 am Post subject: |
|
|
Acolyte
Joined: 30 Jan 2006
Posts: 65
Location: Hursley, UK
|
| goffinf wrote: |
| AndreasMartens wrote: |
As you've noticed, this is not supported, may I suggest you ask for it to be added?
http://www.ibm.com/developerworks/rfe/?PROD_ID=532
One thing to note, with Digest auth the server *never* sees the full password. The digest itself should be stored and the server compares to that.
|
Yes I'll do that.
| AndreasMartens wrote: |
This is my favourite of your choices, with the note above; you shouldn't be retrieving the password, but merely retrieving the digest.
|
Hmmm you've said that twice now. But the WS-Sec Username token when using a digest password, that digest is generated anew each time by creating a one way hash from the original password, the time stamp and nonce. So I don't see how it can be stored. What am I missing ?
|
Ah, that one. I'm not a huge fan of using timestamp+nonce in the digest for that very reason. It comes down to a choice of risk:
1. Risk exposure in the mechanism the server is retrieving the plaintext password to compute a digest to compare with
2. Risk replay attacks using an intercepted UsernameToken
Now even with 1) replay attacks are possible (just harder), which is why I prefer to protect against them using a binary certificate; you can sign your message+timestamp using a certificate and still perform authentication using your UsernameToken.
cheers,
Andreas |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
