I want to import the wsdl from some private server on azure. They (server owners) have issued us a certificate and also have whitelisted the outbound IP's of my Azure service. I added private key certificate on my Azure service.
After that I followed this article and created a new API management instance and tried to import the wsdl file from their server URL but its giving me following error "Unable to download specified file. Please ensure the URL is valid and file is publicly accessible."
It was quiet easy if I had a VM and with whitelisted IP's. I could've used SoapUI testing tool on the whitelisted IP machine in which I can provide the p12/pkc certificate as well, but I'm not able to do it on azure. Any help will be appreciated!
Since only the outbound IPs of your App Service have been whitelisted, the request to the private server can only come from there. Both APIM (and the CORS proxy used to load the WSDL) have different IPs.
One way to approach this would be to have a simple proxy app on your App Service which proxies requests to the private server (with some security of course) and use that URL to load the WSDL. Also, in APIM, you would have set the backend of your imported API to the proxy endpoint.
Another approach would be to whitelist your APIM IP instead but loading the WSDL would still fail because of the CORS proxy used. In this case, you could either
Acquire the WSDL file manually and upload it
Create an API in APIM which just returns the WSDL
Also, do note that the outbound IPs for both APIM and App Service may change with specific configuration changes.
Related
Just have a quick a question regarding best practices.
I am connecting to a 3rd party api via soap over HTTPS.
To do this I have simply added a service reference to my application by entering the 3rd party wsdl address.
In my C# application I have simply instantiated the service passed in my api key and can successfully retrieve data.
I am aware that this would of failed if the servers ssl certificate didn't meet the following requirements.
the URL in the certificate matches the URL I'm posting to
the certificate is valid and trusted
the certificate has not expired
However, is this secure enough? Is it possible for the ssl certificate to be hijacked or faked? Do I need to store a copy of the valid certificate locally and check the server certificate against the local copy?
Thanks
Ant
I'm a not good at Web services and C#. I looked at other threads but I can't seem to find a solution. I think because I'm using SSIS I can't use WSE or WCF approaches.
I'm looking for a solution to exchange data between an application server and a secured web service. Overview:
There is a PFX file present which contains the client certificate and the private key.
The PFX is installed on the application server.
I can't approach the service endpoint through a browser e.g. internet explorer. Even with a certificate.
I received a SOAPUI project with already the bindings and methods defined (Can't insert the URL). I just needed to reference the PFX file in the settings. I compile a test for a method in the form of a SOAP message and I succesfully receive a response.
I need to generate the following SOAP header structure:
Picture
Now in C# how can I realize the same effect as in SOAPUI? At first I tried manually composing the soapmessage and posting it to the service, but I think this is not possible, because I can't seem to generate a security binary token. Now I'm thinking about generating proxy classes. Since I don''t have acces to the URL endpoint, I'll have to use offline versions of the WSDL + XSD's. Can the proxy class approach work with the web service security?
Basically you need to write custom script to consume web service in SSIS. First you need to install certificate on local machine. Then you will be able to consume it. SSIS provide support for web service, so you can use it. SOAPUI request is equivalent to web method.
MSDN Documentation: Call a Web service by using a client certificate for authentication.
Frequently, Web services must authenticate applications that call the Web services. The Web services must perform authentications of calling applications before the Web services can perform authorizations. One authentication technique is to require applications that call the Web service to present a client certificate.
When an ASP.NET Web application tries to call a Web service that uses
certificate authentication, you may receive an "access denied" error
message. When a console application or a Microsoft Windows Forms
application calls the same Web service, you do not receive an error
message.
This behavior occurs because the computer maintains two different
certificate stores: The local machine store: An ASP.NET Web
application looks in this store to locate client certificates. The
local user store: An interactive user application looks in this store
to locate client certificates. Typically, when an interactive user
application installs a client certificate, the client certificate is
installed in the local user store. Therefore, the client certificate
works for interactive user applications. However, the client
certificate does not work for ASP.NET Web applications.
To enable an ASP.NET Web application to use a client certificate, you
must install the client certificate in the local machine store. When
you install a client certificate in the local machine store, the
client certificate is only available for user accounts in the
Administrators group and for the user who installed the client
certificate. Therefore, you must grant access to the client
certificate for the user account that is used to run the ASP.NET Web
application.
Note You must have the Microsoft .NET Framework 1.1 Service Pack 1
(SP1) installed to use client certificates in the local machine store.
Additionally, when the ASP.NET Web application calls the Web service,
the application must export the client certificate from the
certificate store and then add the client certificate to the Web
service call.
Below are resources which would provide some starting point.
HOW TO: Write a Simple Web Service by Using Visual C# .NET
How to call a Web service by using a client certificate for authentication
Client certificate authentication with web services in .NET
Using authentication certificates to connect to web service
Accessing a web service and a HTTP interface using certificate authentication
Creating and Using C# Web service over HTTPS – SSL
We have created a downloading client-service model application in which a WCF service is hosted on one of our servers and the client application is distributed among the partners.
Partners are provided with unique pin using which they can authenticate themselves with the WCF service and can place requests for downloading to the WCF Service.
The clients connect to the WCF Service through Windows Azure Service Bus within which we have created a namespace using which client applications can connect to the service.
Every namespace has a Default Issuer and Default Key. We have embedded this Default key in our code when connecting to the service bus.
Somebody told me that the key needs to be secured and you need to get the application signed in order to protect the embedded key. Is that true?
Do we really need to secure this key?
If yes then how? and Is there a way we can simply provide authentication in Service Bus which identifies the clients from their pins and and allows only a set of people to access the service bus namespace?
OR
I'm uselessly getting worried on such points? :)
We are using Service Bus Relay.
I have been reading about SAS and ACS and it seems according to the documentation that SAS is not supported for Relays. Following is the link:
"Support for Service Bus relays will be added in the near future."
http://msdn.microsoft.com/en-us/library/windowsazure/dn170477.aspx
I am unable to understand how to use ACS for authenticating clients. The information provided in the Windows Azure documentation are all bouncers for me and I can not relate them to anything no matter how hard I try.
If somebody has any information for my concerns then please help me with proper links and guidance.
Thanks!
EDIT!!!
I have been searching on this and the following link provides a methodology for creating an unauthenticated client:
http://msdn.microsoft.com/en-us/library/microsoft.servicebus.nettcprelaybinding.aspx
by using following tag in my client App.Config
<security relayClientAuthenticationType="None" />
I have tried this, but getting the below error:
"Generic: There was an authorization failure. Make sure you have specified the correct SharedSecret, SimpleWebToken, SharedAccessSignature, or Saml transport client credentials. MissingToken: Relay security token is required."
I'm looking more about this error. But few questions arise.
If we make the azure service bus accessible without authentication, can somebody simply misuse the service bus for their own advantage?
Do we really need to secure this key?
You store Issuer and Default Key on your server side.
To authorize on the Azure service bus, Service Bus WCF endpoint uses the Issuer and Default Key to create a token that will be signed with the Default Key that means that Default Key will never be sent to Azure.
Is there a way we can simply provide authentication in Service Bus
which identifies the clients from their pins and and allows only a set
of people to access the service bus namespace? OR I'm uselessly
getting worried on such points?
As far as I understood you have already implemented some kind of security on the WCF side.
There is another one way of doing that. You can use ACS to authentificate Clients. By Default Azure relay Service provides Support for the Simple Web Tokens.
Here is the workflow:
Client send UserName/Password( or UserName/Key) to the ACS.
ACS validates whether the credentials are valid.
ACS send the SWT token back to the Client.
Client packs the SWT token onto the HTTP request(for instance into
headers)
Client sends a request to the Web Service with the token in Header.
WCF web Service recieves the token and validates the token with the
secured shared key that was provided from ACS Namespace.(note that
this key is not sent during the communication it has to be manually
copied from the ACS Portal to the web Service config file)
If token is valid then web Service sends data to the Client.
There's a load of stuff to cover, so I'll try to keep it structured, as all good programmers should.. bear with me.
My Environment
.NET 3.5 SP1 Smart Client
Uses WCF+SOAP over HTTP to communicate to server for business logic / data access
Typically uses a custom (username+password) or Windows authentication scheme
Current work aims to extend to include a new Claims-based authentication scheme to facilitate SSO with ADFS
So far...
Main service endpoints using ws2007FederationHttpBinding bindings, configuration set up with Message security via trust/13/issuedtokenmixedsymmetricbasic256 ADFS 2.0 endpoint
Issuer endpoint configured with IssuedTokenOverTransport to HTTPS trust/13/usernamemixed ADFS 2.0 endpoint
Service has federateServiceHostConfiguration service behaviour specified
Created temporary certificate authority (CA) cert
Created temporary certificate signed by CA
Installed certificate (including private key) and made available to IIS app pool process account
Updated service WCF config to use X509 certificate
Client modified with new app’s own Client scheme/mode, programmatically sets up channel factory to ignore errors caused by temporary certificate and disables certificate revocation checks
Username/password credentials are successfully added (via standard WCF ClientCredentials object) to SOAP envelope of token requests
Token is successfully generated by usernamemixed endpoint and is returned to the client
My problem
Immediately following the token being issued, the subsequent call to issuedtokenmixedsymmetricbasic256 endpoint fails with generic error message that the security of the message could not be validated. Inspection of the SOAP envelope result gives no information at all beyond a simple ‘failed’ result enumeration value
Full tracing has been enabled on ADFS 2.0 server, but no events are logged at all in Event Log or event traces to further diagnose
Unable to configure to work in a federated manner thus far; token is successfully issues over usernamemixed endpoint in the ‘test’ environment (the internal ADFS server rather than a remote one). Use of the ‘live’ environment gives a simple unexplained 401 HTTP status code whether using usernamemixed with confirmed and valid credentials, or windowsmixed, when trying to obtain a token
Generally: Resources from Microsoft or other sources are either very scarce, very specific to one situation, and in a couple of cases, completely wrong or misleading
So ask a question already, doofus
Why does the call the issuedtokenmixedsymmetricbasic256 that WCF makes after getting the token fail? How can I diagnose the result? Other than what I've already done - enabling all trace flags in the service host config, checking the event log and event tracing data, what can I do?
Note, if you're about to suggest a link to a screencast/guide/blog/seemingly all-encompassing MSDN article, please stop. I believe I have found them all, tried them all, and what I need at this point - if you can help me please - is an answer to the above question. Not a general resource.
I created a self hosted HTTPS WCF web service running on my Localhost machine. Now i make a request to this web service from a GWT based application hosted on some domain.
I use self-signed X.509certificate which is not approved yet. Whenever my GWT application make requests, It shows an error because of untrusted Certificate. Can i bypass this error from my GWT client code or suggest me an alternative solutions ?
Is there are any other protocol which supports WCF service that we can use for communication and will not trigger the security alert from browser?
Updated
Whole scenario:
You installed a exe in your system, which take cares of WCF web service and importing certificate to your local machine.
You open a GWT based website from your browser. Let's say some.com
some.com continuously polling a request to his/her local machine. Let's say on https://localhost:8098/{someendpoint}
But because of this HTTPS and untrusted certificate. It is not able to make request.
since you said
Let's start with local testing
How about installing your self signed certificate onto the machine on which you are testing the GWT ?
You should be able to double click the certificate and follow the prompts/wizard to install it.
This applies to development only (for production you'd need a proper certificate)