Hello All,

I am rather new to webMethods. I have built a webservice, which is being called using SOAP.

I would like to see a sample SOAP request which uses authentication part.

I have created an ACL list for my user and assigned this user the Execute permissiong.

Now how do I provide this in my SOAP Message.

Probably this is quite stupid for most of you but any help would be appreciated

Thanks

Amit

Amit,

I’m not sure that I fully understand your question. The soap client typically sends the soap message over http or https. The client supplies the authorization information as HTTP header variables, not in the body of the soap message.

The way in which you specify the authorization varies depending on what client you are using. The webMethods-supplied pub.client:soapHTTP and pub.client:soapRPC services provide an “auth” record structure for you to supply the authentication type (usually “Basic”), username and password.

A plain ole java client that uses the HttpUrlConnection class to send a soap message would use something like the following to specify the authorization information:

//Create connection to the server 
URL u = new URL(server); 
URLConnection uc = u.openConnection(); 
HttpURLConnection connection = (HttpURLConnection) uc; 

//Set connection parms 
connection.setDoOutput(true); 
connection.setDoInput(true); 
connection.setRequestMethod("POST"); 

//Set connection authorization 
String userInfo = userName + ":" + password; 
BASE64Encoder encoder = new BASE64Encoder(); 
byte[] userInfoBytes = userInfo.getBytes(); // I18n bug here! 
String authInfo = "Basic " + encoder.encode(userInfoBytes); 
connection.setRequestProperty("Authorization", authInfo); 

Other soap testing utilities or development environments like .Net accomplish the same thing, but in different ways.

Hope this helps,

Mark Carlson
Conneva, Inc.

Amit,

I wouldn’t say a particular approach is inappropriate until I knew the full context of the situation including the security requirements of your company and the presence or absence of existing security infrastructure.

If your company already supports the wsse security and encryption extensions to the soap standard you can write a custom soap processor (explained in the IS Soap Programmer’s Guild) to extract the wsse tokens and signatures from the soap:header and pass them to the portions of your company’s ID management or security libaries in order to perform decryption and validation of the security tokens. As the wsee standard is still in draft status at this time (Sept 2003), I’m not sure your company would have this in place.

If you need to use soap extensions to support encryption or security tokens, you may be better off finding out what approaches are supported by your company’s ID management tool(s) and investigating the easiest way to access the tools from within webMethods IS.

Jeremy Epstein is webMethod’s Director of Product Security. He and his team have done extensive work with ID management vendors such as Netegrity. Your friendly webMethods account rep could put you in touch with him if you need further details on how to plug something like Netegrity into your integrations and web services.

Mark

I realize this is an older thread, but hopefully still appropriate. I have created a SOAP RPC WSDL file in wM 6.1 that is being made available to a JSP developer. We’re running into what looks to be the common issue that everyone deals with, authentication. When the flow’s executable permission is set to Anonymous, the JSP page interacts with the web service with no issues. Once the ACL is set to anything else, a user name/password is needed. Not sure how to pass this information.

From reading the webMethods documentation and other forum posts, I am still having a problem determining what some of the options are to resolve this issue. Can I utilize basic authentication via the provided SOAP RPC processor, or do I have to configure a custom soap processor? The custom SOAP processor would parse out the soap header to retrieve the user name and password information, then invoke a service based on the qualified flow name.

Are there any built in functions or options on the JSP side that would allow the authentication information to be passed to webMethods without creating custom header variables?

Does anyone know if wM version 6.1 would support the WS-Security protocol that was recently approved?

Michael-
What was your resolution on this question? I am looking at the implementation of WS-Security now, and curious if you have done anything with it?

The direction we went with did not involve WS-Security. From what I was told, webMethods is starting to look at implementing support for WS-Security, but it is not available in the current 6.1 release.

That being said, we ended up passing username/password information by using standard HTTP/HTTPS basic authentication. When you make a call into webMethods to invoke a service that has an ACL other then “Anonymous”, webMethods utilizes the basic authentication information to verify the permissions. When I passed the basic authentication direction out to the JSP developer, he was able to understand and implement, but I do know that there is a lot of information about it on the internet if you do a good search.

As far as WS-Security support, I’m not sure if they have an “official” timeline on incorporating WS-Security at this point in time. They’re probably waiting until enough customers complain about it not being available.

We also followed same thing using http/https Basic authentication in our WS integration using SOAP RPC transport and so far no issues in the production.

But nice to know about WS-Security support,i believe definetely WM will include this feature in their future release.

Regards,
RMG.

Fabric 2.0 will support SAML and WS-Security. I’m not sure when WS-S support will be added to IS.

I recently (last week) created a custom soap processor that extracts a SAML assertion from the soap header and then makes a call to Netegrity to get a decision on whether the user is authorized to invoke the requested service.

A custom soap processor was required in order to have a single security enforcement point and to eliminate the need for individual web services developers to deal with SAML (or Netegrity).

A SAML assertion is just an XML document, so I just passed the header in node form to queryXMLNode and parsed out the pieces that I needed.

Our client app (webMethods Portal) still uses basic authentication to get into IS, but the web service is never invoked unless the SAML assertion contains the right attributes to get an authorization decision back from Netegrity.

HTH,

Mark