ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » Windows Authenticated Web Service access

Post new topic  Reply to topic Goto page 1, 2  Next
 Windows Authenticated Web Service access « View previous topic :: View next topic » 
Author Message
dilse
PostPosted: Tue Sep 26, 2006 9:34 am    Post subject: Windows Authenticated Web Service access Reply with quote

Master

Joined: 24 Jun 2004
Posts: 270

Hello All,
My environment includes WMB V6 and WMQ V6. I have a message flow that invokes a Web Service which is a security-enabled one. When I am making a request to Web Service it is responsding with a getsockopt error "No connection could be made because the target machine actively refused it."

When the Web Service was made anonymous I was able to get the response from the Web Service. Please let me know how could I overcome this security problem and what do I have to do to rectify this problem.

Note: I am running the Message Broker service under the account that has the authorization.

Thanks in advance,

DilSe..
Back to top
View user's profile Send private message
alexey
PostPosted: Wed Sep 27, 2006 7:34 am    Post subject: Reply with quote

Acolyte

Joined: 18 Dec 2003
Posts: 62
Location: Israel

If the service is secured with http authentication, you can create corresponding fields in HTTP header before sending the request to HTTP.
For example for HTTP Basic Authentication you need to add:
Code:

SET OutputRoot.HTTPRequestHeader."Authorization" = 'Basic '||base64Encode(user||':'||password);
-- you'll need also to create standard http fields:
SET OutputRoot.HTTPRequestHeader."Content-Type" = 'text/xml;charset=utf-8';
SET OutputRoot.HTTPRequestHeader."Content-Length" = 0;   
-- and may be others too


You need to have a function (you can download some Java, for example) that can encode a string to Base64 (MIME) format.

If it is not HTTP Basic authentication, you need to read the RFC and see which fields to create in the header.

Alexey.
Back to top
View user's profile Send private message
dilse
PostPosted: Wed Sep 27, 2006 8:07 am    Post subject: Reply with quote

Master

Joined: 24 Jun 2004
Posts: 270

Thanks a lot for your response alexey.

This Web Service is enabled with basic security mechanism that checks for the userid that is requesting the Web Service. My Message Broker is running under a userid which has the authorization. As far as I heard from IBM, Broker does not send the userid that it is running under when Broker makes a Web Service request. I am trying to overcome this problem by adding UderId and Password fields to the HTTPRequest header.

SET OutputRoot.HTTPRequestHeader.UserId = 'xxxxxxx';
SET OutputRoot.HTTPRequestHeader.Password = 'yyyyy';


But the Web Service request is failing with the getsockopt error.

I will try the Authorization in the header line.


Can any one help in this aspect?

Thanks in advance..

DilSe..
Back to top
View user's profile Send private message
jefflowrey
PostPosted: Wed Sep 27, 2006 8:32 am    Post subject: Reply with quote

Grand Poobah

Joined: 16 Oct 2002
Posts: 19981

You can make all the guesses you want about how the Web Service wants you to authenticate against it.

Or you can just ask the Web Service provider what they are expecting, and then figure out how to accomplish that in Broker.
_________________
I am *not* the model of the modern major general.
Back to top
View user's profile Send private message
dilse
PostPosted: Wed Sep 27, 2006 10:16 am    Post subject: Reply with quote

Master

Joined: 24 Jun 2004
Posts: 270

Web Service authentication involves taking the 'userid' that made the request and check to see if it is a domain user id or not. If it is a valid network user id, it will authenticate.

I need to make sure what userid did it pass when Message Broker makes a request. Is there anyway that I can check to see this.

Thanks,
Dilse..
Back to top
View user's profile Send private message
jefflowrey
PostPosted: Wed Sep 27, 2006 10:24 am    Post subject: Reply with quote

Grand Poobah

Joined: 16 Oct 2002
Posts: 19981

You need to find out how the Web Service receives the User Id.
_________________
I am *not* the model of the modern major general.
Back to top
View user's profile Send private message
dilse
PostPosted: Wed Sep 27, 2006 12:58 pm    Post subject: Reply with quote

Master

Joined: 24 Jun 2004
Posts: 270

Thanks for the response Jeff. I found the process they are validating with.

It is a .NET Web Service. On IIS WebSite Properties "Directory Security" there will be an option called "Integrated Windows Authentation" which our Web Services are checked for.

Apart from "Integrated Windows Authentation" option there are Other options like "Anonymous Access", "Digest Authentication" and "Basic Authentication".

But Our Web Service is using "Integrated Windows Authentication" option. I am not sure what are the HTTPRequestHeader parameters for this kind of request.

alexey,

Could you add anything to this? I think you were on the right path specifying the the Authorization but when I tried to put user and password values in the statement but it is showing the statement as an error. Please let me know how should I specify this.


Thanks a lot,
DilSe..
Back to top
View user's profile Send private message
alexey
PostPosted: Wed Sep 27, 2006 1:53 pm    Post subject: Reply with quote

Acolyte

Joined: 18 Dec 2003
Posts: 62
Location: Israel

"Integrated Windows Authentication" is the same as NTLM, it uses a kind of hash for user/password, usually encrypting with Kerberos.

So you can do one of the following (ordered from best to worse, for my opinion):
- Ask the WS provider to configure a default user for NTLM access - worked fine, from my own experience.
- Use an open source Java HTTP Client that supports NTLM.
In the Broker it can be used as an external code or inside Java Compute Node. I'd suggest to try Jakarta's commons: http://jakarta.apache.org/commons/httpclient/features.html
- Use a HTTP sniffer on the WS server and learn which fields in HTTP header are used for NTLM and how the hash is passed. Then fill them in the Broker accordingly. I did not find any documentation on that - may be you could find.

You can read more, if you're interested, about HTTP authentication in ftp://ftp.isi.edu/in-notes/rfc2617.txt


Quote:
I tried to put user and password values in the statement but it is showing the statement as an error.

If you've used my sample, I guess you did not define a base64 encoding function - you need your own function to encode base64 - it does not exist in broker.

Good luck,

Alexey.
Back to top
View user's profile Send private message
dilse
PostPosted: Wed Sep 27, 2006 2:37 pm    Post subject: Reply with quote

Master

Joined: 24 Jun 2004
Posts: 270

aleaxey, Thanks a lot for the response.

Currently I am preparing the 'HTTPRequestHeader' instead of letting Broker to do it default in a "compute" node.

Quote:
Ask the WS provider to configure a default user for NTLM access - worked fine, from my own experience.


If there is a user configured for NTLM access, do I still need to set any extra parameters in the "HTTPRequestHeader" for Web Server while making a request?

Please let me know as this seems to be a simple change.

Thanks, DilSe..
Back to top
View user's profile Send private message
alexey
PostPosted: Wed Sep 27, 2006 3:53 pm    Post subject: Reply with quote

Acolyte

Joined: 18 Dec 2003
Posts: 62
Location: Israel

dilse wrote:

If there is a user configured for NTLM access, do I still need to set any extra parameters in the "HTTPRequestHeader" for Web Server while making a request?

You don't need to add anything - IIS will automatically authenticate with that default user.
This is not very secure, of course.

Alexey.
Back to top
View user's profile Send private message
dilse
PostPosted: Thu Sep 28, 2006 7:58 am    Post subject: Reply with quote

Master

Joined: 24 Jun 2004
Posts: 270

Hi alexey,
Thanks for your response but I have a question on this solution. Let us assume that WS team created a default NTLM user. But how can it authorize the Message Broker HTTP Request when Message Broker is not sending any userid associated with it? How can we make the Web Service to tell to use that default user when requesting from Message Broker.


Appreciate your help in this matter,

DilSe..
Back to top
View user's profile Send private message
alexey
PostPosted: Thu Sep 28, 2006 2:16 pm    Post subject: Reply with quote

Acolyte

Joined: 18 Dec 2003
Posts: 62
Location: Israel

Quote:
But how can it authorize the Message Broker HTTP Request when Message Broker is not sending any userid associated with it?


I'm sorry for being not accurate enough - by "default" user I ment the "anonymous access" user, the one that is used when no other is specified.
The whole point of the anonymous user is to use it when no user specified by the client. As I've said, this is not very secure thing, but the default user has no permisions, usually, and can be set on the specific WS in IIS only.

Alexey.
Back to top
View user's profile Send private message
dilse
PostPosted: Fri Sep 29, 2006 7:31 am    Post subject: Reply with quote

Master

Joined: 24 Jun 2004
Posts: 270

Hi alexey,
As I said 'Anonymous' was already working for us but this was considered as the non-secure option. That is the reason Web Service team wants to use 'Integrated windows Authentication' which uses the hashing technique in order to authenticate with Web Service. I used a .Net tool that can directly speak to the Web Service without any issue but when I checked it was sending an extra called "Authorization" which has "Negotiate" and a hashed key. So I am not sure how to generate this hash key. Here is how the Authorization looks like.

Quote:
<authorization>Negotiate TlRMTVNTUAADAAAAAAAAAEgAAAAAAAAASAAAAAAAAABIAAAAAAAAAEgAAAAAAAAASAAAAAAAAABIAAAANcKI4gUBKAoAAAAP</authorization>


Please help if anyone has any idea on this.
Appreciate all your help.

Thanks,
DilSe..
Back to top
View user's profile Send private message
dilse
PostPosted: Fri Sep 29, 2006 9:10 am    Post subject: Reply with quote

Master

Joined: 24 Jun 2004
Posts: 270

Hi All,
HTTP authentication is a basic requirement for Web Sevrvices. Then why do you think they didn't provide any support for accessing Web Services securely.

Quote:
What are the digfferent security options available for Message Broker to access Web Services in a secure manner. I think a lot of people are using HTTPRequest to access the Web Services How did you achieve the security when accesing.


Please share your thoughts as it is very urgent for us.

Thanks in advance,

DilSe..
Back to top
View user's profile Send private message
alexey
PostPosted: Fri Sep 29, 2006 3:41 pm    Post subject: Reply with quote

Acolyte

Joined: 18 Dec 2003
Posts: 62
Location: Israel

Hi!
I've managed to find some documentation on this:

Here's an FRC about NTLM authentication
http://www.rfc-archive.org/getrfc.php?rfc=4559
And here's some mode tech docs:
http://bofriis.dk/spnegoarticles.do

- may be you find those useful.

Think again about Jakarta's common HTTP Client instead of boker's HTTP request - it seems they've already implemented NTLM.

Alexey.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Goto page 1, 2  Next Page 1 of 2

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » Windows Authenticated Web Service access
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.