I have a silverlight application with classic User Login process.My problem is that when I listening the browser with Fiddler application,i see request uris clearly which means:
myriaserviceurl/binary/?username=asd&password=12345
this isnt secure isnt it?
Do RIA Services have an encryption? How can i encrypt data between client and server?
Thx your answers.
You need to setup SSL in your hosting site, then change the Authentication Domain Service's attribute like following.
[EnableClientAccess(RequiresSecureEndpoint = true)]
public class AuthenticationService : AuthenticationBase<User> { }
With that attribute, any client accessing that service will access it over HTTPS. If the hosting site doesn't have HTTPS enabled, i.e. SSL is not set up, then clients would not be able to access it.
The hard part is setting up SSL for your hosting site, but it isn't too hard.
You can follow this link for further explanation.
Their is packet and transport encryption - as you are using HTTP - I think you need transport to avoid the URL being seen. In Silverlight, that means SSL
But then again, I'm still getting my footing on all this... :)
Related
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.
We are starting a very large web based service project. We are trying to decide what hosting environment to use. We would really like to use Google App Engine for scalability reasons and to eliminate the need to deal with servers ourselves.
Secure logins/registrations is very important to us, as well as using our own domain. Our target audience is not very computer savvy. For this reason, we don't want to have the users have to sign up with OpenID as this can't be done within our site. We also do not want to force our customers to sign up with Google.
As far as I can see, I am out of luck. I am hoping to have a definite answer to this question. Can I have an encrypted login to our site accessed via our domain, without having to send the customers to another site for the login (OpenID/Google).
Thanks.
The hardest part is getting around the cookie issue. While you can do secure and custom logins against https://yourdomain.appspot.com, you cannot set a cookie there that will work on http://yourdomain.com.
Here is what I propose:
When you need to log the user in, send them to https://yourdomain.appspot.com. If they enter the credentials properly, create a one-time token and place it either in the datastore or in memcache. Give it a lifetime of a few seconds.
Then redirect the user back to http://yourdomain.com/authenticate?token=mytoken (obviously substitute the names as appropriate), check to make sure that the token is valid and has not expired, and if all is clear, set the appropriate cookies and expire the token.
I think that'd work just fine. Hope it helps!
As of June 27, 2012, App Engine supports SSL for custom domains.
http://googleappengine.blogspot.com/2012/06/google-app-engine-170-released-at.html
There is nothing stopping you from creating your own authentication/registration mechanism with Google App Engine. The only problem is that Google App Engine currently only supports HTTPS via https://yourid.appspot.com and not your Google Apps Domain (i.e. https://www.foobar.com). However, this is on the product roadmap for future support (SSL for third-party domains). Note, also on the product roadmap is built-in support for OAuth & OpenID.
Update: Another option may be to use a proxy server (like Apache with mod_proxy) and map your domain to the proxy server and then the proxy server can proxy the HTTP and HTTPS requests to Google App Engine. The requests could be proxied to the appspot.com domain behind the scenes. I haven't actually done this, but I believe it should work. However, this would give you a single point of failure at the proxy server which basically defeats the purpose of Google App Engine's high-availability and scalability. This would definitely just be a short-term solution until Google supports SSL for third-party domains or OpenID.
Depending on whether your threat model can accept a non-encrypted link on the "last hop" to GAE, you can use a proxy to handle SSL from the browser. Here's a HOWTO I wrote up on using CloudFlare to get always-on SSL:
http://blorn.com/post/20185054195/ssl-for-your-domain-on-google-app-engine
This isn't structurally any different than the way SSL from Google will work, it's just that Google-provided SSL will terminate within G's network rather than just outside it. If you're trying to protect against Firesheep, CloudFlare (or any other SSL proxy) will do fine. If you're worried about snoops on the trunk connection between CF and Google, you may want a more sophisticated solution.
I am working on writing a OMS implementation. I have verified that service is compliant with the service and schema definitions.
When trying to set up the account in Outlook 2007 to test the service, it allows me to use an https address, but not an http address.
According to the documentation (http://msdn.microsoft.com/en-us/library/bb277363.aspx) "The URL of the OMS Web service can be either http or https, but it is https if not otherwise specified"
I have not been able to find any doucmentation that would explain why Outlook will not even let me try to do anything in the wizard if the service url does not start with https.
The error that it returns when a http address is entered is:
The web service address is incorrect or corrupted. Check the web service address or contact your administrator
I have also tried creating a temporary cert on my local machine to test the service, but outlook is rejecting the cert because it is not valid.
Is there any way to test the service or run it over http?
You are not alone in seeing this error, we've also come across this issue, one of the 3! comments on the msdn documentation also reports an issue with using http (http://msdn.microsoft.com/en-us/library/community/history/bb277363.aspx?id=2)
Apart from exposing your service as https there doesn't seem to be a way around this :(
Connection Security
To protect the information as it is
transferred over the Internet, OMS Web
services are required to support SSL
(Secure Socket Layer) encryption. SSL
can be used to establish more secure
connections on untrusted networks,
such as the Internet. SSL enables
encryption and decryption of messages
exchanged between client and server,
thereby helping to protect messages
from being read during transfer.
http://msdn.microsoft.com/en-us/library/bb277361(v=office.12).aspx#OfficeOutlook2007OMSMobileServicesGuidelinesPt1_CommunicationProtocols
We have a Silverlight app which we wrote which calls a Silverlight-enabled data service. The Silverlight app cannot require a login, as it is required to present data to the unauthenticated public.
We have some schmoe who took the time to examine our Silverlight app, one way or another figure out what service it is calling, and then wrote his own client to slurp off the data so he can post it on his site and pretend like it is his. We need to prevent this.
How can i limit my data service somehow to ONLY accept requests from my silverlight app? I tried using the allow-from domain uri setting in the clientaccesspolicy.xml file to limit access to the service only from the domain in which the silverlight app sits (say mydomain.com). This did absolutely nothing though, and the service is still serving up requests to clients from outside the domain. (I tested this by putting my SL app on a different domain under our control).
What is the proper/best/most effective way to limit the data service so only our app can use it? Thanks!!!
I'm using SL 3 and .NET 3.5.
The clientaccesspolicy.xml tells the Silverlight application which Webservice it can consume. Not preventing people accessing the Webservice.
You can try using a authentication login even though its not required. This prevents 'schmoes' accessing your webservice.
Also use Dotfuscator to prevent 'schoes' to disassemble your Silverlight application and acquire the login.
Silverlight webservice security follows the same patterns you'd use for ASP.NET security, especially services exposed to AJAX. The best way to do make use of ASP.NET's authentication.
RIA Services is an even better way to handle this. It rides on top of the ASP.NET authorization, but validates on both the client and server-side automatically to combat service spoofing. It let you take care of both client and server-side authorization by adding attributes to your methods indicating that the method requires authorized access, and by which groups or users if you need to be specific.
In addition to wire-side security and obfuscation, remember that clients can attach a debugger to Silverlight applications running in their browser. See this example from MSDN Magazine's Security IQ Test, November 2008.
In a silverlight application, I want to access the page the silverlight .xap file from an HTTP subdomain, but have the web services access a different subdomain for sensitive information over HTTPS.
I set up clientaccesspolicy.xml at the root of the subdomain and it lets the silverlight app access its services over http, but not over https. It gives the cross domain access error that it would give normally without a clientaccesspolicy in place.
I know that browsers themselves have a lot of restrictions about mixing http and https. Am I trying to do something that is not allowed?
Check out:http://silverlight.net/forums/t/12741.aspx
You can either make https calls to the
same domain or http cross-domain
calls, but not https cross-domain
calls.
This is described in
http://msdn2.microsoft.com/en-us/library/cc189008(VS.95).aspx
(see "If not HTTPS" in the matrix)
By JohnSpurlock
This is out of date since Silverlight 2.0 was released. You can now do most cross-domain scenarios with the appropriate configuration. http://msdn.microsoft.com/en-us/library/cc197955(VS.95).aspx
The important thing to note here that is not in the above information clearly is you must have access to the "ROOT" level of the domain request, and the clientaccesspolicy.xml must reside at that level.
If for example you have a production environment that your application is behind a load balancer that directs traffic as most large companies do to your application via the URI, you then have a little bit of a problem.
Example: http://mydomain.com/MyApplication/* goes to your server, where your app resides.
http://mydomain.com/clientaccesspolicy.xml is where the policy exists.