You may want to check out this thread. Ultimately the problem I had was due to a limitation in Skuid that they are going to try to remedy in the next build. https://community.skuid.com/t/external-rest-data-source-authentication-issue
For connecting to Dunn and Bradstreet, this configuration should work:
We highly recommend entering your Username and Password under “Authentication Details” so that they will be protected — you can merge in the Username and Password values into the x-dnb-user and x-dnb-pwd headers using {{$Auth.Username}} and {{$Auth.Password}}, respectively. If you do this, the Username and Password are injected server-side into the authentication HTTP Request, such that it is impossible for a user making use of this Model Service to know what the Username and Password were. If you do it the way you currently are, then a user would be able to use the JavaScript Console to inspect the AJAX requests that Skuid makes to the server and determine what username / password were transmitted to DNB to obtain an Authorization token.
The only other piece that you’re missing is Common Request Headers — expand the section entitled “Headers to send with every request” and this will bring up an editor allowing you to define headers that will be transmitted with every non-authentication request to this Model Service. For DNB, you need to send an Authorization header with every request, containing the value of the “Authorization” parameter returned in the Authentication response body. To obtain this value, you need to use the merge: {{$Auth.Response.Headers.Authorization}}. (NOTE: technically you need to be getting {{$Auth.Response. Body.Authorization}} , but there is a bug with the current release of Skuid that is not incorrectly switching the Auth Response Body with Auth Response Headers, and there is no current way to access the Auth Response Body. This will be corrected as of Skuid Banzai Update 7).
Thanks Zach and Raymond. I was able to set it up, and I appreciate such helpful response.
However, when I create a model, I don’t see the field names. DnB’s JSON response seems to have these defined so I am a little unsure if this is something that I am not setting up correctly my end or what.
Also, I tried setting up the search so that a user can lookup an account name via the DnB web service…but it looks like that is not working either. Here is the response I get on the UI
And, here is how my UI config looks like…
Am I missing something? Appreciate the help. Looks like Skuid can really help us get rid of a lot of Apex callouts 
What Service URL are you connecting to?
Here is the XML of the page
Here is the XML for a working page example using the /V5.0/Organizations endpoint:
Street Address
{{LineText}}
Which produces a basic table looking like this, with the Table defining a Search Condition mapping to a Condition on the Model so that you can search for company names. In the DNB Sandbox, there’s only ever one result that gets returned, but this should work in a real environment as well.
Try using V5.0 , and have your Service URL be relative to your Model Service’s base URL, e.g. /V5.0/organizations. See the example page XML I posted below for a working starting point.
One of the key concepts for working with REST Models is Path to Contents, which is very important to understand when you are trying to display Tables on Models with multiple rows. Very often, your REST service will return an object as its response, and buried somewhere within this object is an Array of rows that you want to use as the “contents” of your Model. However, you need to tell Skuid where to find this Array. This is the purpose of the Path to Contents property on the Model. For the DNB example here, you need to click on Path to Contents, then click the arrow next to “MatchResponse” , then click the arrow next to “MatchReesponseDetail”, and then click the RADIO BUTTON next to “MatchCandidate”. Notice that MatchCandidate is an ARRAY. This contains the array/list of DNB records that match your search criteria.
