I work for a company that develops a software product that processes bank transactions and gives the user insight into his/her spending. Our customers (usually banks) integrate the product into their online banks.
I have a question about securing the communication between the online bank, and our system. Before I ask the question, I want to give you some background.
The bank will usually install our system on a set of servers in their hosting environment.
We offer a number of ways to integrate:
Web services - In this case the bank will make calls to a set of REST services on the server, and then generate a webpage with the results (on the server side).
Iframes - In this case the bank will embed iframes in their online bank webpages. The iframes contain webpages rendered directly from our web application.
Inline widgets - In this case the bank will embed JavaScript references on their pages. When the document loads, the JavaScript widgets will render themselves, using AJAX calls. They communicate with a proxy on the bank server, which in turn communicates with our webapp.
We currently have a custom solution where we generate and sign security tokens for the users, and pass these with the requests.
But as banks have very strict security policies, they would feel better with us using a known and trusted security protocol for the communication. It is a big concern, which we want to address.
So the question is, which protocol is best suited for the integration use cases I listed above? There is a plethora of single-sign-on standards out there, and solutions like SAML, oauth, etc. I get the feeling that these solutions might be an overkill for my situation.
I want to find a solution that is simple. As the servers will run side by side in the same hosting environment, and trust each other completely, there is no need for the end user to authorize one or the other (or being redirected between, clicking buttons to give access to the app).
That is, the security protocol should not require any intervention from the end user. The end user simply logs into his/her online bank, and via secure communication has access to the data from our web server.
So...any suggestions?
Thanks a lot!
OGG
After some deliberation, we decided to use 2-legged OAuth (online bank uses consumer key and consumer secret to sign requests to our app).
OAuth signature can either be put in a request header, or request parameters. It nicely solves our problem, as the REST requests can be signed, and the IFRAME src URL-s can also be signed (all communication is over HTTPS).
For those interested, a couple of references:
This article shows using OAuth with IFRAMEs: http://developer.tradeshift.com/blog/cross-site-user-verification/
This article mentiones some security issues with OAuth, and how threats can countered: http://software-security.sans.org/blog/2011/03/07/oauth-authorization-attacks-secure-implementation
Related
My scenarios is simple and perhaps not only me deal with. I have an webservice that is used my a number of my mobile apps. I would like my webservice only be accessed from my mobile apps but I don't wish my apps's user be bothered with registering an account. How can I achieve that kinds of security?
I have read about API KEY and OTP, but it doesn't really convince me.
It isn't possible to do what you want 100%. The reason is that if the security is in your Mobile App, or travels over the internet, it is theoretically possible for someone to read your code or scan your traffic and then impersonate your Mobile App.
However, you can get good results with simple server side checks. EG, from your Mobile App, add a variable into HTTP calls which is checked by your backend. And, most importantly, use SSL. You can make this more complex as well, such as providing a token from the server and then requiring this token back on every call.
It's not unbreakable... but it will deter the casual hacker. And it will probably only take you 10 minutes to implement.
I'm going to integrate a Moodle-based application into my website wherein all data/activities being posted in this Moodle-based application can be retrieved by my website and vice versa.
So, is the Moodle web service enough to access all the data in that Moodle application?
Yes, you should be able to use web services. No, not all data is accessible out-of-the-box.
Things you can do with the webservices:
Retrieve a list of users, courses, assignments
Upload files
Create notes
Send messages
Enrol to courses, groups, cohorts
Check grades
On your Moodle site turn on web services and go to /admin/webservice/documentation.php to get a full list of existing functions you can call.
You can see some examples of this implemented in the Moodle Mobile App:
User: http://docs.moodle.org/26/en/Mobile_app
Dev: http://docs.moodle.org/dev/Moodle_Mobile
If these satisfy your requirements then yes web services should be sufficient as they are.
If they do not then you can extend the web services as a local plugin to provide richer functionality, which would be limited by your development capacity rather than the system itself. To port all of the features of some modules to web services would be a significant undertaking, but there are some low-hanging fruit to get activity lists, forum discussions/posts, choice polls, etc.
Web services is a better approach than exposing the database to an external system as it allows you to utilise the core APIs to improve integrity.
I am currently working on a single-page web application. The web app will make calls to a REST-like API for authentication and data storage. We are currently in the middle of securing the application, and have worked out a strategy securing the site so only registered users can gain access. But one thing we also want to do is securing the API from others to write their own applications, or access it in any other way than through our web application. The problem from my view is that the API will be open for everybody and not only for my web application.
Anyone who knows how to do this, or who can point me in the right direction. Because right now, don't have a clue.
Considered using certificates and validation?
Your API should only be accessible, if the session of the client is authorized. That's pretty much anything you could do.
There are complex approaches like using client- and server-side encryption or something really basic: render a secret in your webpage that validates the user again on every request.
You could check the headers, where the original request comes from. And so on...
But as most of that is public in a users browser, anyone could read it and adopt it in a third party app.
So save yourself and the people that really want to do a third party app some time and provide a public API :)
Simplest way will be to use OAuth 2.0 ( supports both authentication and authorization) which you need.
Also ensure you secure the data on wire using TLS (HTTPS) and any of the options below
1. HTTP Digest
2. OAuthn 2.0
3. Certificates ( Shared secret)
Stick to HTTPS+Oauth2 for now.
You could lock down your you API to accept requests from known IP's. Also depending on how your network infrastructure is designed, your web application can sit in a DMZ and your API on an internal network accessible only by servers in your network, one of which will include your backend API (This article here info https://www.digitalocean.com/community/tutorials/5-common-server-setups-for-your-web-application has some tips). For better security, a secure network design in addition to an application security framework implementation like OAuth2 and HTTPS (mentioned above). For API's, I've found that resource based authorization works better than role based authorization. Lastly, constant review of your security setup is vital as things change all the time. A good approach to this is Threat Modelling described by OWASP here https://www.owasp.org/index.php/Application_Threat_Modeling
I need to serve a SOA application though an AJAX/REST API. The service need to be sold to customers which will be able to host a JS on their sites which will let their users communicate with our webservice.
Needs:
the customer only should put a one line in its page, no server side code
the script should authenticate and download the API js code to communicate with the enabled services (depending on the licensing options the customer buy)
the overall path should work without having the customer's users to see logins nor certificates
I can't find a pattern to fullfill the previous requirements at the same time. Do you have suggestions?
I've considered various options, but at the minimum thet reuire to install server side code on my customer's machines, but I cannot do it (they have their own third party hostings, of various nature).
Thanks a lot,
Giovanni
We're in the early stages of designing a RESTful/resource-oriented web service API for a computational lingustics application. Because many of the resources we plan to serve are rights-encumbered, a key design decision has been to specify the platform so that each resource provider can expose their own web service that complies with the API spec. This way, the rights owner maintains control over their content (and thus the ability to throttle or deny access at will) and a direct relationship with the consumer, while still being able to participate in in the collaborative network.
At the same time, to simplify the job of writing a client for this service, we want to allow a client access to the distributed service through one end-point, with the server handling content negotiation and retrieval from the appropriate providers.
Right now, we're at an impasse on authentication/authorization schemes. One of our number has argued for the (technical) simplicity of a central authentication registry, but others are concerned about the organizational complexity of such a scheme.
It seems to me, based on an albeit limited understanding of the technologies, that a combination of OpenID and OAuth would do the trick, with a client authenticating with the end-point via OpenID, and the server taking action on the user's behalf with the various content providers using OAuth.
I've only ever seen implementations (e.g. stackoverflow, twitter, etc.) where a human was present to intervene, and I still need to do more research on these technologies.
Would a scheme like this work for an automated web service, or would it make the client too difficult to implement and operate?
OpenID does assume the user is present to drive a web browser to interact with their OpenID provider and do that initial authentication. But you could have the user authenticate to the end-point with OpenID, and there get an OAuth authorization for their client's automated use.
You should be able to do this without making the client too difficult to implement, particularly if the client is on a platform that allows it to spawn a web browser to drive that initial OpenID bit.