I've been struggling with this for a few days, and I hope someone can suggest some solutions.
I have a self-hosted WCF service, the main interface to this service will be a Silverlight application that is hosted in a non-IIS, potentially shared, environment.
I'm aware of the TransportWithMessageCredential and a custom authentication validator. The only requirement of this seems to be that the host has HTTPS and a valid SSL certificate. However, there are certain enviroments the product will be operating in where they don't wan't the hassle of paying for and maintaining a certificate, or the shared environment doesn't allow SSL.
The easy answer would be to tell them to find a new host/admin, but I've been asked to see if there are any other fesible authentication mechanisms.
Any suggestions?
Thanks
Without SSL there really isn't any way for you to secure the users credentials "across the wire". You "could" do some encryption in the Silverlight app, but this really amounts to obfuscation vs. "real" security.
The only option that I can think of in this scenario would be moderately secure would be a 3 factor solution such as giving all the users SecureID key fobs.
We had the same problem. We made the installer for the WCF service that creates a self-signed certificate, adds it to the system certificate store and configures the binding with HTTPS port. The Silverlight application had a link to download this certificate from the WCF service. So users could download this certificate and install it in the Trusted Root certificate store.
Related
I'm looking to implement a running express server using https, powering an AngularJS application. Currently I have the majority of the application running just on http, but would like to switch over. This isn't a publicly available application. Am I ok to simply use self-signed certificates to implement this in our production environment? Or should I be going through a trusted certificate authority even for internal use?
Using OpenSSL seems pretty simple to generate the key and pem files... but I feel dumb when it comes to acquiring something through a trusted authority. If it's recommended that I DO in fact use a trusted CA, and not self-signed, could someone point me in the right direction on where to go for this?
The answer is "it depends".
You can certainly use self-signed certs, but you will have to manually make sure that all your endpoints are configured to trust your self-signed certs. This is what a trusted certificate authority is used for. The browser has pre-built trust for certificates issues by various public certificate authorities and, in turn, they agree to follow certain procedures related to issuing their certificates. If you go through that process, then browsers will automatically recognized and trust https connections using your certificates (assuming everything is as expected with the connection). If you don't go through that process, then you have to manually tell each endpoint that is going to access your application to trust your certificates. For closed applications with a small number of controlled endpoints, this is very feasible. For open applications or applications with a wide variety of endpoints (random browsers, phones, etc...), this is difficult.
And, you do not want to "teach" your user base to either ignore security/certificate warnings or to blindly trust things that the browser tells them might be insecure so you want to not leave this to your users - you want to pre-configure the endpoints to trust your new self-signed certs.
To give you an example, there are home security camera systems that have web access. If the only ways you need to do web access are from 2 or 3 different browsers, it's not really a problem to use a self-signed cert and configure those 3 browsers to trust it.
But, if you had some web application that many different people would access, then it wouldn't really be practical to manage the certificate trust on a rotating set of browsers and it would just be a lot less complicated and a lot more likely to be secure to use a trusted CA.
Personally I prefer using CA trusted certificates over self-signed certificates for production environments (or even developer environments) since you need to trust/add exceptions or overwrite programatic SSL checks when you are using self-signed certificates.
If you decide to use CA trusted certificates, I recommend looking into Certbot + Let's Encrypt. It is a trusted CA and supports most of the famous servers. It is also free and really easy to use. The only downside is that you need to renew the certificate every 3 months. This too can be automated depending on your platform/server.
Is it possible to access Rally's SOAP services from Silverlight? I am able to access the service from a .NET 2.0 proxy in a desktop application, but not via a WCF client proxy in Silverlight. I get the following familiar exception,
System.ServiceModel.CommunicationException:
An error occurred while
trying to make a request to URI .... This could be due to attempting
to access a service in a cross-domain way without a proper
cross-domain policy in place, or a policy that is unsuitable for SOAP
services. You may need to contact the owner of the service to publish
a cross-domain policy file and to ensure it allows SOAP-related HTTP
headers to be sent. This error may also be caused by using internal
types in the web service proxy without using the
InternalsVisibleToAttribute attribute. Please see the inner exception
for more details.
I believe the problem is caused by trying to make a cross domain request from Silverlight, which requires a cross domain policy file installed on the server. If this is the case, why does the desktop application not require such a policy?
I'm not a Silverlight expert, but this looks like a cross-domain scripting/security sandbox that Silverlight imposes to make sure that Silverlight clients don't make requests to sites other than the server/host from which they were downloaded, unless the Silverlight client is specifically granted that right by the service provider/devloper. In the error message above:
"You may need to contact the owner of the service to publish a cross-domain policy file and to ensure it allows SOAP-related HTTP headers to be sent."
I think the "owner of the service" means the owner of the Silverlight host, rather than the "external" webservice (in this case, Rally).
Desktop and/or console apps wouldn't have this same sandbox restriction. You would probably encounter the same issue trying to access another vendor's webservices via a Silverlight client.
You might find this Silverlight-specific thread:
Cross Domain Policy
Helpful for the specifics of how to setup and configure a Silverlight cross-domain policy file on your server.
Silverlight was built with security in mind. That means cross site scripting from the Silverlight application is turned off by default and must be enabled on a case by case basis. A .NET desktop application, on the other hand, generally has far greater security permissions and can call whatever web services, COM objects, and native APIs it pleases.
The way you work around this issue in Silverlight is to create a service on your server. The Silverlight client code calls your server side service which in turn calls a third party web service. The server side service can bet .NET, java, whatever. Web servers can generally call whatever they like -- problem solved.
Resolved this myself by using the extended permission features available in Silverlight 5. Since the xap is deployed on an internal internet, this solution was acceptable.
How can I authenticate to a web service hosted in IIS that is secured with Integrated Windows Authentication?
Do I use HTTP headers to add username and pwd?
I am trying to call this web service from UNIX in C.
I'm rather a newbie to IIS myself, and I'm just starting to dance around this topic, but I saw your note and thought it was crazy that no one has answered in so long!
I believe that the typical way that windows authenticates is Kerberos. You may have to go through some gyrations to get the Windows Kerberos server to get you a ticket that you could put in the SOAP header. That is at least the direction in which I would start researching... but it could heavily depend on your Windows domain configuration. At the very least, you'll probably need to do quite a bit of poking into Windows Domain configurations and concepts.
I have a Silverlight application that needs to retrieve some data from my database. This data is sensitive. Because of this, I only want my Silverlight application to be able to access the data. How do I ensure that only my applications can access the services that expose this data? Is there a way that I can validate a client attempting to retrieve the data?
Thank you!
These might be of interest:
Using ASP.NET Secure Services and Applications Services
Build Line-Of-Business Enterprise Apps With Silverlight, Part 2
MS Whitepaper: Security Guidance for Writing and Deploying Silverlight Applications
Well, everything your SL application does could be spoofed. So direct answer is NO, you cannot ensure that only your application will access to the data.
But there are number of options. For example you can implement authorization and then authenticate your user. In this way you can ensure that only users you trust access to the data.
Another option is to make spoofing harder. For example you can include sort of "secrete" token to all your requests. So other application will need to steal this token. This harder to achieve.
I think this question is more pertaining into implementing a web service or wcf service with authentication and authorization. If your service takes care of it, then you can be ensured about your data. Your silvelight app is just calling the service.
Whoever download the xap can decompress and reverse engineer your code, so your best bet is to build a web service as others suggested. Silverlight Ria ships with a full blown authentication membership that you can leverage.
We are developing an application that needs to talk to some hardware (serial port) on the machine, and most of what we do is WPF and .net, so an xbap seems logical.
My concern is with the certifcates. I have seen a bunch of people showing how to create and self sign applications, but then the user is required to install that to their machine manual to trust the root. I am curious if we purchase an cert from say Verisign if that requirement will then go away?
I have no problem if there is a prompt requesting full trust, but I do not want my remote users dealing with installing certificates.
Thanks
If you purchase a code signing certificate from a trusted authority then the users will not need to do anything with certificates.
If your certificate comes from a trusted authority, the users won't generally need to worry about it (where it becomes an issue is if you let your certificate lapse). If you're a member of Code Project, you can get a "cheap" certificate from one of their partners. More information here.
there is a solution here =D
XBAP full trust deployment
create your own certificate and deploy full trust. 0 cost. if you're looking something like secure layer cert, you may head on http://www.comodo.com/business-security/digital-certificates/ssl-certificates.php?entryURL= for free SSL