Two customers want to use SharedSecret into their cXML file and we don’t know what to do to use that instead of using username/password. Does we need to create an XML file with the informations, … ? Does someone can help us?
Try looking at the webMethods Ariba Supplier OnRamp – I’m not familiar with it (we use something else), but I imaging it has support for Ariba shared secrets.
If you’re not using the OnRamp, you probably need to write a custom receive service which extracts the SharedSecret from the document, and compares it to the SharedSecret value stored against that customer in a database, or TN profile custom attribute.
Sonam
In my past Ariba implementations, the SharedSecret was stored as an Extended field in the partner’s profile. Then, when you receive a cXML transaction from a partner and you validate their credentials, you can then validate their SharedSecret by extracting it from the XML and comparing it to the value in that partner’s profile.
- Percio
Once it is validating with the Extended field, what do I have to do to ask or not the username and password?
Sorry but I really don’t know what does generate the username/password question on the screen.
The customers are sending their orders to wm.tn:receive. After that, it goes to the the mapping according to that customer. I don’t know what is generating or not the username/password question.
I’m assuming you’re planning on having the customers post the cXML documents directly into wm.tn:receive, correct? Don’t do that. Read this article for more details: [URL=“wmusers.com”]wmusers.com
In a nutshell, you can create your own “receive” service, which does not do any username/password validation. You can set the Execute ACL of that service to Anonymous so users can execute it without providing a username/password.
Please understand that this should only be done if it is a definite requirement. Setting an Execute ACL to Anonymous has significant security impacts, especially when dealing with a TN receive service, which will most likely result in data being written to an internal database.
Talk to your partner and/or Ariba to see if they are capable of supporting authentication methods that are invisible to the end user (ex. embedding the username/password in the HTTP header, digital cetificates, etc.)
- Percio
You’re right when you write “I’m assuming you’re planning on having the customers post the cXML documents directly into wm.tn:receive, correct?”
I also read article you mention but they are not suggesting any way to slve the problem.
I can’t create an anonymous user because of the security.
You were talking about to use the username and password into the http url. If we use this, will it avoid to ask the username/password? I don’t think so. Can you elaborate about this please.
I’m talking about having the username and password encoded within the HTTP header (not within the URL.)
As you know, different properties can be set in the header of an HTTP request. One of the properties you can set is “Authorization”. You can set the value of that property to the word “Basic” followed by a space followed by the string username:password encoded in base 64. When you submit an HTTP request to the Integration Server with that property set, the Integration Server will use that username and password to authenticate the request.
I’m not sure if you’re a Java guy, but in Java, setting this property would look somewhat like this:
URL url = new URL( url );
HttpURLConnection c HttpURLConnection )url.openConnection();
connection.setRequestProperty( “Authorization”, "Basic " + Base64.encode( “user:password” ));
So, what I was saying is that, the system from which the users are submitting the requests could set this property behind the scenes. That way, the users would not have to worry about typing in a username and password. This should be avoided over an unencrypted connection though because the HTTP packets could potentially be sniffed and the username/password could be easily decoded.
NOTE 1: I have not personally used this in Production. I also looked for some webMethods documentation on it and I couldn’t find it, so I’m not sure if they would even recommend this practice. The better way to go for automating authentication is probably through certificates. Whatever you do, make sure you get webMethods’ blessings.
NOTE 2: From a webMethods IS standpoint, my role has mostly been that of a developer. I have had limited Admin experience. Hopefully, someone with a little more experience around security and authentication will chime in.
- Percio