I'm building a mobile front-end for my customer's CRM system. CRM data is stored in a SQL Server database in their local network. What will be the best practice to make this data available to mobile app users. Mobile app will be distributed using Enterprise key, not via App Store.
I'm thinking about making a WCF service running on a local server and having access to the SQL server via ethernet. This service will provide basic authentication. But I'm not sure if it's the best way in terms of security.
How to provide access to SQL server data?
A WCF web service can definitely be used as a SQL front end. Windows or JavaScript-based client applications running on hand-held devices have no trouble accessing WCF applications, and there's plenty of sample code out there about using a WCF app as a front-end to databases. Here's a sample project from CodeProject.
Security wise, there are several options: you could create a Login(ID, PWD) function that all non-authenticated user requests would have to pass through before getting to your SQL server. Once the user authenticates, you can create a persistant session or send back to the client a SessionID he/she can use to re-authenticate on subsequent requests. You can also use more exotic and complex methods for authentication/authorization like client certificates and Forms, though on a iOS or Android device that will certainly take some extra work.
Since a public web service, accessing company core data, is a hacker's dream, you can always set up your web service so that it can only be accessed from inside the company firewalls via VPN. If not that, then you can use SSL or message-level encryption.
Related
I'm getting into the world of fullstack development and I'm trying to develop app which front is completely separated from backend (front is being served from node server and backend is java).
Now, the issue - how should I get about securing my app?
I'd like to have many fronts and many backend instances connected through load balancers and I'd like to keep all the state on client, so I can without any issue switch to another backend server and continue as nothing happened.
Currently I'm using OAuth2 tokens but I'm concerned about security and stealing the tokens, which are completely stored in cookie on user side. Also, The app (obviously) stores those tokens somewhere, so another instance of my backend app wouldn't accept the token. In best case scenario I can implement some mechanism that would automatically request a new one and in worst case I'd have to login again. I don't want that to happen.
Also, here I have a problem with social auth. Allright, I'm receiving token from Google on front, but giving it to backend and creating a user there is major pain, I have to write a lot of code manually to create such user and save it.
And again, I'm not certain about security level of this solution.
So the question is basically - currently, what is the best way to secure an app which should have completely separate front and backend, which would have no issue with switch backend server between requests?
As regards tokens being stolen from the Client: you can't do anything about this. It is up to the client to protect themselves. What I mean is, if you need a username and password to access a service, and the Client is infected with a key-logger, and a hacker steals those credentials, there is nothing you can do on the server side to protect against this.
As regards your idea of multiple back-ends, this is a common feature of any system with multiple application servers. For example, if you have multiple web servers and want any request to be routable to any server. For this, you need a central database which stores any information which needs to be shared. It's slower, obviously, but much more resilient.
I have tried Google with queries similar to the title of this question, but haven't found anything useful.
Background: I am building a web app and would like to add a user authentication level to it. I cannot imagine anything worse than building a user authentication system from the ground up, so I want a quick solution.
I'm looking for open source software I can host on my server that provides an auth layer I can connect to, with multiple user accounts
Criteria:
I want to host the software on my own server
Provide a log in screen that works with multiple sign in strategies - twitter, facebook, vanilla email, etc.
Persists users to a database (preferably postgres) and persists session data
Preferably lets me store a minimal amount of data per user, like key value store
Has a client-side (Javascript) API, like Facebook's JS, so I can use this auth service on multiple sites. Namely, I want to use it on localhost or my own file system (when allowing file cookies). Client side JS API exposes methods like log in / log out
Has a server side API (such as exposes local RESTful endpoints) so that when I do build out my server side app for other data storage outside of the user, my app can query the auth service for log in status.
I want to run this stack completely independently of my own app - in fact I want to run this auth service and purely communicate to it from my local dev environment without building any server side app of my own.
I have used Firebase and they do many of the things that I want, including log in strategies and the client / server side APIs, but I want to be able to host my own version of this.
I can't imagine anyone takes pleasure out of building user authentication of any kind, so I'm surprised I haven't found anything in research.
I also know this is an open-ended question, but as far as I can tell I haven't found anything satisfying my requirements.
I like Devise (https://github.com/plataformatec/devise), which is for Rails. It has an active community with a boatloads of plugins available that can fulfill many of your requirements.
I didn't see a language specified; most languages and frameworks have their own implementations. Can you provide more information?
Example: I use the Flask framework on python. In addition, I use the Authomatic library which provides Oauth access for twitter, google, facebook, etc.
What I was looking for is something called a Single Sign On solution. According to this list there is nothing currently that meets my criteria.
Instead I have chosen to just run a local webserver and implement a regular auth flow.
I am building an application in which front end is iPhone and I am using ROR as my backend with mongoDB as my database. It is a kind of chatting application for which I am using jabber protocol and XMPP server. Now I want that when a user is created in my rails app, the same user should be created on the XMPP server. Any help would be much appreciated.
The ideal situation is to have only a single source for users and configure your XMPP server to use that same service.
For example it is common to have an XMPP server authenticate against LDAP, then all user management is delegated to the LDAP server. The XMPP server doesn't handle user management at all, but defers any user related queries to LDAP.
This would ultimately be more reliable than trying to keep two separate systems in synch. If the user management in your case is custom (which it appears to be), it might mean you will also have to add a custom module/plugin to your XMPP server (you haven't mentioned which one you are using) to use that service.
I have a high-level/conceptual question about Shibboleth.
I'm working on the front-end (running Drupal) of a data-driven web app. End-users interact with the front-end to construct data queries, which makes background requests to a caching/archiving data proxy (the "data retrieval service"), which in turn either delivers data from its cache or goes out and queries still more services ("out there") which have desired data. So far so good... it is ornate, but only as ornate as the problem we're trying to solve.
Here's the wrinkle: Some of services queried by the data retrieval service want to implement user-level authentication, so that some users may access their data, but others cannot. For organizational reasons, our identity and authentication mechanism is likely to be Shibboleth.
So, here's my scenario: a user logs in to the frontend using Shibboleth. Now, can my frontend, and in turn, the data retrieval service, authenticate against against external services as the user? And if so, how does that work in practice (what authentication data gets passed from server to server)?
Yes it can - you service has to exist in the identity provider (how it is set up is up to you)
what are web services(Rmi,ejb,soap)? what is the difference between web services and web application? Is it possible to implement web services in web application?
A web service is a way to transmit/expose information in such a way that a Web Service client, which can created in a server script or from a stand-alone program, can call the service for what it wants using methods and functions defined by the service.
One of the benefits of a web service is that it abstracts these methods and functions (and variable types) in such a way that any language that "speaks" web services can use it's own syntax to interface with the service (thus making it cross-language).
Another benefit is that it uses the HTTP protocol (usually transmitting via XML or JSON, but not necessarily either), so it's also cross-platform.
A huge benefit is that an application that typically requires very specific knowledge and software can "expose" information via a web-service. So if you're corporate mainframe has tons of top-secret data that typically requires a terminal client, etc, to get data, certain data can be accessed via a Web Service so that you can have your HR department download and upload timesheet changes from a web site.
A web app can certainly include a web service, but they are not the same thing. You can make a web service using PHP or .NET, and then have a web app written in either language interface with that service, but a web app tends to be an interface for the site you're on, while a web service is about getting info to and from other apps (web or not).
web app is user interface, access by humans, user can browse data , can submit and retrieve data. All user interactivity (the GUI) is done through web pages, but all data is stored and manipulated on the server.
Web service server-based application and meant for interaction with other programs.
A web service is a way to expose some business logic you have over the internet. Say you got a module that connects to the database and does something. You can let other applications on the internet use this module of yours via web services. Web services uses SOAP over HTTP to invoke the request and retrieve the response in XML.
Web application - Person-to-server with HTTP, HTML
Web service - Server-to-server with HTTP, SOAP, XML