My team and me are currently working on quite a large project. We are working on an online game, which will be accessible (for the moment), in two ways:
-Via a web browser, an application full JavaScript(client-side), full Ajax (basically meaning that the UI will be managed in JS client side).
-Via an iPhone application (the UI will be managed by the application itself).
Between the two different applications, the core logic remains the same, so I believe (I could be wrong), that the best solution would be to create a web service (if possible using standards such as RESTful or Rest) capable of perming all necessary operations.
Following this logic, I have encountered a problem: the authentication and identity management of the user. This poses problem as the applications users need to be authenticated to preform certain operations.
I’ve looked into WS-security, but this obviously requires passwords to be stored, unencrypted on the server, which is not acceptable!
I then looked into Oauth, but at first glance this seemed like a lot of work to set up and not particularly suited to my needs (the way that applications have to be accepted does not please me since it will be my application and my application only using the web service, not any external application).
I’ve read and heard about a lot of other ways to do what I want, but to be honest, I’m a little confused and I don’t know what information is reliable and what isn’t.
I would like to note that I’m using symfony2 for the backend and jquery for the client side JavaScript.
Furthermore, I would like a detailed, step-by-step response, because I really am confused with all that I have read and heard.
Thank you for your time, and I hope someone can help me as it’s quite urgent.
Good evening
I'm not entirely sure if this answers your request, but since the UI will always be handled on the client side, I think you could use stateless HTTP authentication:
This is the firewall in security.yml:
security:
firewalls:
api:
pattern: ^/api/ # or whatever path you want
http_basic: ~
stateless: true
And then the idea basically is that on the server, you use your normal user providers, encoders and whatnot to achieve maximal security, and on the client, you send the HTTP authentication headers, for example, in jQuery:
$.ajax("...", {
username: "Foo",
password: "bar"
});
Please note that since the authentication is stateless (no cookie is ever created), the headers have to be sent with every request, but, I figure, since the application is almost entirely client-side, this isn't a problem.
You can also check the Symfony2 security manual for further information on how to setup HTTP authentication. Also be sure to force HTTPS access in your ACL, so the requests containing the credentials are secured (requires_channel: https in your ACL definitions).
Related
I am building a windows 8 application which will be used as the interface to a web service I have running.
I need to find a safe way of encrypting sensitive data to pass, then decrypt it the other end.
Two things I need to do (as they may require separate methods);
1) User will enter a username and password which needs to be authenticated
2) User will enter personal information to be saved.
Now I have looked at many encryption/decryption methods, but I cannot find anything which is common place between the two. For example System.Security.Cryptography is not available within the windows 8 app, and my website can't use CryptographicEngine.
I am basically trying to find the best way to DO what I need to do. Along with a way of actually doing it in code.
You will not be able to use the same namespaces, as you have recognized. What you need to do is settle on a standard crypto algorithm on both ends.
Here is a discussion for one approach on the Win8 side using AES256. http://social.msdn.microsoft.com/Forums/en/winappswithcsharp/thread/8f9ecac4-80d2-47c8-8c41-9d7877565bf5
Here is a solution for doing AES256 with regular .NET
http://msdn.microsoft.com/en-us/magazine/cc164055.aspx
If you just need to secure the channel, then use an HTTPS web service, that's what HTTPS was designed for. The client-side HttpWebRequest class should just do the rest for you.
You'll need a certificate on the web server.
Thanks for looking!
Background
I am building a strictly machine-to-machine web-service (restful) application. The application will listen for requests, retrieve data, construct objects, serialize to JSON and return the JSON object.
This application will ultimately be used by other web applications as well as iOS apps, Android apps, and even desktop apps.
The existing code that I have inherited makes a distinction based on how the service was called in terms of HTTP verbs (GET, POST, etc).
Question
In this day and age of machine-to-machine communication, is the HTTP verb even relevant any longer? Could it in fact be constraining for future adoption of the service API to base the code around HTTP verbs?
Update
fmgp provides a clear answer to "why" these verbs are used, but I feel should I clarify my concern:
Will other platforms such as iOS or Android (for example) be able to originate HTTP verb-based calls like GET and POST? If the answer is "no" then I assume that we should stay away from relying on these verbs and instead build the desired action into the request URL as a parameter.
In RestFul applications, you have a verb foreach CRUD operation:
Create: POST
Read: GET
Update: PUT
Delete: DELETE
Everything claimed "restful" will work the same way according to this philosophy.
There's nothing standard in that, just a clean, good designed, easy to understand programming style. Of course you may want to do all operation with only GET and some query parameters as soon as your client and server can handle it.
I am in the process of designing an application that users will be able to log on remotely and use - via a web interface.
Security is of paramount importance (think credit card and personal banking type information)- so I need to make sure that I get the security aspect nailed down - HARD.
I intend to provide the application functionality via traditional (stateful) web pages , as well as web services.
For what its worth, I am intending to use web2py as my web application framework.
Is there a list of guidelines I can follow to make sure that I have all areas covered?
One stop shopping: https://www.owasp.org/index.php/Main_Page
Read that and take every suggestion to heart.
you should consider at least the following:
authentication. getting users to log on in some manner. which authentication method they use depends on what you aim to provide
privacy. making sure the information they send is only visible to them and your application and not an eavesdropper.
in the simplest case SSL can take care of both of the above. it will always provide encryption but can also be used to authenticate or at least make some simple authentication mechanism more secure. one thing to look at is security of ssl. ssl is suceptible to a man in the middle attack particluarly when the users already have a trust relationship with, say, their employer - who can them proceed to install an ssl gateway which is effectively a mim.
authorisation. making sure users are only allowed to see what you want them to see and no more.
this really depends on technology you are using.
non reputidation. making sure the user cannot dispute the actions they perform
this is a very open ended question. legally this is seldom (never?) used so it depends... something like signed logs of user requested actions for example is probably enough.
Your biggest threat, by far, is writing server-side webapp code that introduces vulnerabilities in your web application layer. This is not something you can checklist. For a starter, make sure you are 100% comfortable with the items in the OWASP Top Ten and understand how to code safely against them. If you are not expert in web application vulnerabilities, strongly consider hiring someone who is to help review the web layer. At the least, i would consider contacting a security testing company to perform some form of penetration testing, preferably with a code review component.
If you ever do anything with credit card data, you will need to comply with the PCI DSS which will require at least quarterly remote-testing from an Approved Scanning Vendor.
The two web service(rest) are running on separated JVM instances with its own authentication.
The services is used by external user's log in, the server2 is for customer service team. After external use log in, he can call server2 for query. Oppositely, after customer service guy log in server2, he also can call server1 to change external user profile.
In another word, these two services trust each other. It seems like a SSO between them. Since both of them run on internal environment, I am wondering if there is a simple solution to implement it.
Thanks
I've had a good experience with JOSSO:
The setup is relatively simple (gateway and partner applications)
Non intrusive (no big changes needed for your application to work with it)
Based on JAAS
Supports various stores (LDAP, XML, DB...)
Works with Java, PHP and ASP (we use Java and PHP at our company and it works flawlessly)
You've got a lot of different options:
You could roll your own authentication system. It'd be exactly what you need, but you get to debug it yourself.
You could deploy Kerberos. A little old-school, but it clearly differentiates login servers from trusting servers.
If you're already in an MS-heavy environment, Active Directory might be just the tool.
OpenID is the new kid on the block; as used by StackOverflow :) but implementations of servers and clients might be harder to find.
LDAP is an easy way to get site-wide directory services; actually doing authentication against it might be a bit more work. (Which is why Active Directory is as popular as it is -- combining LDAP with Kerberos into one mechanism for site-wide authentication and authorization. Neat.)
We developed a web service which is accessed by various platforms clients, for example it is requested by c++ and Java enabled clients.
I want to use simple, effective encryption Algorithm which is easily decrypted by JAVA - C++ and JAVA script based clients.
Why not just deliver your service over HTTPS?
Why write anything?
The most widely-compatible method of Web Service security that is still actually secure is Transport with Message Credentials. This uses SSL (https) for transport-layer security, which handles the encryption aspect, and passes a username/password in the SOAP header, which handles the authentication side.
It is not as secure as mutual-certificate authentication, which also gives you non-repudiation, but it is good enough for the vast majority of applications.
Several other options exist, but T/MC is usually the easiest to get working across platforms (.NET, Java, C++).
If you need to add javascript into the mix then I'm afraid you may be disappointed, as that is a serious game-changer. Although there do seem to exist various JavaScript SOAP Client implementations, SOAP is a second-class citizen in the JavaScript world, and I don't believe that any existing libraries have proper support for WS-Security or really WS-Anything except for the basic profile.
If you want your web service to be consumable by JavaScript then you want to go for REST instead of SOAP. I know that .NET (WCF) is pretty good at this but I'm not too sure how well Java and C++ fare. I believe that the transport security should be simple enough (it's just SSL), but it's likely that you'll have to implement some custom authentication code to get it working across platforms. Either way, you definitely want to go the SSL route; please do not try to roll your own encryption scheme.
If you already have the service implementation which is Base profile compliant and you want to keep on supporting various platform clients, extend your current service with WS-Security/WS-Trust. This will allow for encrypting/signing the content of the message, without loosing interoperability.
Depending on which toolset you used for your original implementation, the inclusion of WS-Security can be as easy as 'flicking a switch and selecting some options in your configuration file' (WCF/ASMX+WSE).
Since you mention the various platforms client side, I assume this is one of your main requirements.
Hope this helps.
You can simply use HTTPS which is easily implementable in both C++/Java clients (e.g. using the GNUtls library). On the server side, you will only need some small configuration changes.
Apart from the different request code, you have to create a self-signed SSL server certificate and install it on the clients. Of course this is not a good idea if the web service is public, where you need trust (= a real SSL certificate). But if it's only used internally, self-signed certificates are a quite good solution, as long as you keep the private key secret.