I have made a Java EE 6 application where a user can browse a set of questions, add new questions and so on. The user can optionally log in so that he/she gets "credit" for adding the question or reporting it as bad.
Now I want to make a iPhone application where the user can do pretty much the same. So the answer is web service I assume. I have not worked with web service before but I see there are at least to alternatives: SOAP and REST.
Which one should I choose? I want the user to be able to log in from the application as well a as browse the questions in the database...pretty much many of the actions you can do on the web site.
I don't know much about the security and overhead they introduce.
Also I want the user to be able to retrieve the list of questions thorugh the web server and have the option to save it, so he/she won't need to have internet unless he/she wants to update it. Can I achieve this with both web services?
REST has less overhead than SOAP (WSDL contract, XML messages, supporting frameworks) so when the client is a mobile device REST seems more suitable. You could use JAX-RS (Jersey) to easily create REST services on the server side. The client request consists of the url structure and/or parameters like http://yourserver/questions/view/342 (to view question 342) or http://yourserver/questions/search?q=REST+vs+SOAP (to search for questions about REST vs SOAP). The response can be anything you want, but XML or JSON is pretty common.
Choosing REST means you will be leaning heavily on the HTTP protocol. For security a common approach is to use HTTP Basic authentication in combination with https. Basic authentication means you add an 'Authentication:' header to your HTTP request containing a Base64 encoded username:password pair. Note that Base64 does not encrypt anything, it just obfuscates. To avoid eavesdropping you need to use at least https meaning requests are encrypted using the server's public key. These requests can only be decrypted with the server's private key. To use https you need to set up the server with a certificate. If you want to avoid warnings about the certificate being 'untrusted' it needs to be issued by a recognized SSL certificate provider. For testing you can just generate it yourself.
Finally you asked about saving a list of questions for offline usage. This is a concern of the app, not of the service. To do this you need to store the retrieved data on the device and access that data if the device goes offline. I am not an iPhone developer, but I can imagine you could use a flat file or some lightweight database to store the data. When the device is offline, the app component that retrieves data should switch from network access to local storage access. Also some app functionalities like adding a question might need to be disabled. If you don't disable these, you would need to temporarily store any data entered by the user and send it to the server when the device comes online again. This could be a bit tricky to get right so my advice would be to leave this for later.
You can take a look at this previous SO post for some guidance. I would recommend using REST, it seems to be less messy than SOAP and Java has support available for it as shown here.
Through the use of annotations, you can simply created a facade to which users will connect. In turn, this facade will call the relevant logic which I am presuming you already have.
Well on a simple search REST vs SOAP, you will eventually get to this
There are plenty of other articles and even in-depth research papers, so it's only a matter of - do you really want to get serious with your research VS not really
Good luck!
Short answer: Yes, you can achieve that with web services.
Web services are only a facade to your system - they can expose (or not) any behavior you want to. If you have security concerns, you'll have to approach them anyway in both methods.
Personally, I'd use a RESTful approach as its usually simpler to implement and use. From Wikipedia:
A RESTful web service (also called a RESTful web API) is a simple web
service implemented using HTTP and the principles of REST. It is a
collection of resources, with four defined aspects:
the base URI for the web service, such as http://example.com/resources/
the Internet media type of the data supported by the web service. This is often JSON, >XML or YAML but can be any other valid Internet media type.
the set of operations supported by the web service using HTTP methods (e.g., GET, >PUT, POST, or DELETE).
The API must be hypertext driven.[11]
So you'd have a URL, say http://mywebsite.com/users and perform HTTP actions (GET, PUT, etc) on them. A GET request on /users/17 could return user 17, for instance, while a POST request on it would update said user.
As for login, when your users "log in" you would call a GET method that sends username:password (probably encrypted) and returns a login token. Every time the user executes an action, you would send said token with the request as an additional parameter.
Related
I'm developing a RESTeasy JSON API under JBoss-As 7.
I have another separate web-server.
I am developing with JAVA on server-side, and on client-side with Javacript, JQuery, AJAX.
So, I have 2 distinct *war*s, let say they can be accessed as following:
https.//localhost:8443/services
http.//localhost:8080/web
Now I want to secure these two guys; RESTeasy API and web-server.
Let me tell about my structure:
I keep the users in DB with username-password. These are the only users for now.
I have a login page to authenticate my users (I don't want http basic auth popup and any workaround about that)
The clients of REST API are browsers (not web server). The static page is load, and then some other dynamic things are load through REST API, calling within from browser using JQuery, AJAX, whatever.
All communication can be through SSL/TLS, no problem.
For the future, scalability (clients other than web-browsers, ability to authenticate with social network logins, etc.) should be in mind.
My scenario is as following:
Client is browser.
Client wants to access a web page web/aaa.html which is restricted to authenticated users.
Client is redirected to login page: web/login.html
Client filled the FORM and sent to ... either,
a) to the rest-api, or
b) to web-server,
not sure (So, here you have an implicit question).
But in any case, what a or b should do is the same:
Check username-password. Let say they are checked and the user is authenticated.
From now on, I should have got these two things at the same time:
1- Client is authorized to navigate the restricted pages.
2- Client will be authorized on REST API calls.
So, I need these 2 things at the same time happen, after authenticating in login page.
I have read lots of things, about authorization in REST API, with tokens, keys, etc. and yes I also have heard about Spring Security, Apache Shiro, etc.
And yes, I do not want to implement a new security framework by own and I will use one. I imagine that some framework can produce/check tokens etc. for me.
Before Spring Security and Apache Shiro, I want to know about resteasy skeleton key JBoss module.
There are these sources:
https://github.com/resteasy/Resteasy/tree/3.0.1.Final/jaxrs/examples/oauth2-as7-example
http://docs.jboss.org/resteasy/docs/3.0-beta-2/userguide/html/oauth2.html
But, they didn't seem to me very explicative, and also I am not sure if they are what I need.
Is there someone who knows how to configure skeleton key (or in general JBoss App layer) and give me useful example to achieve what I've described, please?
Or, could you give me some other advice/example to achieve my goal, especially noting that my question is about "how to implement"? I don't see where to begin.
Thanks in advance.
For securing REST Services, We can use following framework
OAuth (Open source - RFC6749)
Apigee
I have a website that sends dynamic information to users via servlets. It is stateless and there are no logins. This specific site uses a decent amount of doPost() and doGet() calls from client browser to server.
My question is, if someone reads my source, they can easily just rip out my public facing servlet URL's and have a free API at my web servers expense.
How can I keep this from happening? Is there some kind of authentication package I can use between JavaScript and Java that doesn't add noticeable delays? I would only like users on my webpage to be able to call the public facing servlets.
Not an expert but this may help : http://oauth.net/ as I know big web API's like twitter use this.
Two ideas:
REFERRER HTTP header to make sure the client is coming from an
authorized source
require authorized users of your service to provide an API key tied to their website.
I would like to build the following project:
public REST API back end which can be accessed by any authenticated client
front end with static files in HTML/CSS/Javascript with Backbone.js jQuery calls to the REST back end
In fact, there are three parties in my architecture : the front end, which is a client of the back end, the back end and the user which wants to authenticate on the front end login page.
What is the best way to secure the three parties involved in this architecture ?
In fact, I believe it is just impossible to do a secure app on the front end if I do everything in javascript, so I intend to delegate the authentication/authorization to a proxy layer on my server front end. What do you think about that ?
I intend to use OAuth to secure my REST back end, but I am not sure if I have to use the 2 or 3 legged implementation. What is the right approach in this case?
UPDATE : while searching a deep more on SO website, i found this thread which is exactly what i would like to do, except i want to use Java on server side and not DotNet. If i understand well, in fact my web site is like any client of my REST API, except it is the only one which has the right to create new users' accounts. Because, if my REST API is only accessible by OAuth (like Twitter's one), who can perform the user account creation before ? Am i right ?
One major concern with security with this architecture is testing. Automated tools will have trouble testing this system for common vulnerabilities like SQL Injection, Direct Object Reference. A useful tool for testing strange architectures is OWASP's open source Zed Attack Proxy or the proprietary BURP proxy. Testing will be time consuming and requires someone who has a good understanding of web application vulnerabilities. We often refer to these people as Pentesters.
A RESTful form of keeping session state is to use an HMAC to protect the values from modification. However, this is a misuse of cryptography because it opens the door for attack. An attacker can brute force the secret key used in your HMAC and then modify values such as his session id or otherwise gain access to another account on the system. Cryptography should only be used when there is no other option. This vulnerability is prevented entirely by storing session state in a database, which isn't RESTful.
first poster :)
As the title says, I am looking to create a desktop app which will notify me of changes on facebook and new emails, and the facebook part (the first part I've tried) is baffling me. I've never worked with an api before, and have no idea how to integrate facebook's api with this desktop helper I want to create. I will be using java to create this desktop helper.
Thanks in advance!
Here are few pointers for you to get started. Please feel free to ask for clarifications and I will edit my answer accordingly:
For facebook, you can actually pull all those info via their API. There are a lot of types for API, but Facebook specifically use REST API over http.
To simplify, think of it as making an http call with specific parameters and you will be getting an output back.
In order to use facebook API you need to understand their protocol including authentication/login and how to request for things that you want. This would require some reading to their documentation which is pretty complete and available at http://developers.facebook.com/docs/.
For the description of their API URL and the input/output documentation, you could directly jump to Graph API Documentation http://developers.facebook.com/docs/reference/api/.
In order to call their API via HTTP from Java, you could leverage HttpClient library from Apache Http Components project http://hc.apache.org/. They have plenty of tutorial and examples for how to make http call using HttpClient
For combining with all other emails accounts (per your question), you need to deal with SMTP or IMAP (whichever email protocol that you are planning to combine with Facebook). This is already built-in to Java via their Java Mail API collection
You then can poll this data on interval basis to get an update from Facebook and your mails
Once you have figured out how to get the data, the rest is just following a good MVC framework. That means separating out your presentation, data and controller (application logic). Make sure that you are separating the classes for #1 and #2 and each of them put their data to normalized data format that then get feed to your View (presentation layer)
Here's a scenario:
I have a java front end (RCP/SWT) app which currently has no authentication support.
I have to however, add security to this application so that it gets deployed in different enterprise envinronments. I have a few approaches which I thought I would share with you all here and take your inputs. Please note that there are no strict requirements yet, so.. I would like you to consider typical and non-typical enterprise network security models.
Approach 1
Create a 'Security' webservice that
the thick client would invoke, on startup.
The client queries the security for the current authentication mode and receives the implementation class of the authentication as a soap attachment. The class received, will not have the logic for authencation, rather it would just describe the UI and the events on the UI. (The client could make use of a GUI toolkit such as Thinlet?)
Once the class is loaded, a UI relating to the currently set authentication method is displayed to the end user.
Advantages:
This approach lets me handle different authentication schemes. For instance, if the app has to authenticate against user names and passwords stored in a database, a screen with UserName and password fields would suffice. However, say the user were to do a network logon that would involved typing in the network name, the UI would contain three fields. If the security model at the client network dictates ntlm/SSO based authentications, the user won't see a UI. This will also leave scope for future authentication methods - for instance, supporting a captcha specific logon screen/ biometric stuff / whatever.
Approach 2
KISS (Keepin in yea.., Simple)
User name and password are usually the only two credentials required by all of the known authenticating mechanisms?
Have the thick client query the webservice and let the webservice handle the entire authentication process.
I am not sure how realistic/feasible/commonly used the above mentioned approaches are. Appreciate your help.
I'd certainly not recommend transmitting class definitions as SOAP attachments. A network classloader would make more sense, but is still not needed in your situation.
Put in the client what belongs there - the UI. Have the multiple screen types ready (i.e. defined as classes) on the client and activate each of them depending on a single value passed by the server. For example if AuthenticationType.CREDENTIALS is passed, go for username/password. If Authentication.SMART_CARD is - go for smart card.
If you want to distribute the application and later implement different auth screens, then use Java Web Start. Thus all clients will be guaranteed to be running the latest version.
After knowing that your requirements impose some limitations, take a look at this network classloaders article.