I am new to eJabberd, after setting up the server and be able to send messages between users I want to be able to create rooms from our backend server (not from our clients).
I read this article:
https://docs.ejabberd.im/developer/ejabberd-api/oauth/
But I did not understand how can I use the api from our server side (for example, to automatically create rooms for our users), how can I obtain a token for the server to use the API?
Thanks.
You should consider using mod_rest - http interface to post data to ejabberd. You can read more about configuration & examples here.
Do consider adding some restrictions so that only your server can use the http interface.
Related
Is it possible to block connections to a web service (server) from outside its domain?
For example consider a web app that fetches data from Twitter's API using Twitter's "application only auth". The web app's client uses AJAX to call it's own server, which in turn calls Twitter's API with Twitter's token.
While the token is never exposed to the client side code is there anything to stop an outside server side app from calling the web app's server using the URLs used by the client and for example exhausting the Twitter tokens rate limits?
Is it possible to block connections to a web service (server) from outside its domain?
Certainly. Set your web server's access control lists to drop connections from outside of your IP range. Alternately, install a firewall. That's very straightforward, but I suspect you mean something else by "outside its domain?"
From your description, you seem to be really asking whether you verify that you're only talking to your own client application. As a general rule, no. You can authenticate users. That's easy. If the user isn't logged in and authorized to use your service, you don't forward requests to Twitter. But you can't authenticate applications.
If you're going to accept any user who shows up, you can't stop them from using whatever client they want. There is no way to ensure that it is your unmodified client if you've allowed it to be run on their machine. They can always modify it, and they can always send you arbitrary traffic from other programs and you can't tell the difference. On the network, bytes are bytes.
It's not all hopeless; there are things you can do. See https://stackoverflow.com/a/9183066/97337 for another version of this question, and links to several other versions of the question. (They're not exactly duplicates in how they're asked, but they all wind up being basically the same answer.)
You should secure your web service with user and password security or certificate security. The basic idea is that the web service client must authenticate in order to call your web service.
Here are some technics (there are others or variations):
1) HTTP basic authentication and HTTPS
2) Mutual SSL authentication - Also called two-way authentication, is a process in which both entities authenticate with each other. The server presents a certificate to the client and the client present a certificate to the server.
3) With SOAP web services you can use WS-Security standard.
4) OAuth framework
5) With Rest services you can use options 1), 2), 4). Or implement one by your own. This are good recomendations.
As you can see, there are a lot of ways to secure a web service.
Is it possible to have the API Manager redirect an incoming client API call to a back-end URL customized according to the client data?
In our back-end we're activating different instance URLs for each client, e.g.:
client1.api.domain.internal
client2.api.domain.internal
...
Clients connect to the API Manager to a unique shared address, e.g. api.domain.ext, and then clients shall be routed to the internal API accordingly (the parameter is bound to the client profile).
Is this achievable via configuration or is it necessary to develop a custom component?
You can use API manager.
Publish one API-A to the clients to subscribe publicly via publisher. Define another internal API-B (dont publish it) where do routing logic based on the clients' requests.
Point the API_B as the production URL to the API_A. So, requests will be routed to your internal API-B, where you can define your mediation logic.
But for defining mediation logic, what you have to do is, open the API configuration in a TEXT editor and need to edit or via source view of the management console. You can follow ESB guide for various mediators to pick a right one.
Hope this helps!
This is a similar situation to the one raised in this question:
Javascript Calling a Rest API with App Name and App Password - How Can i Secure it
Here is the architecture overview:
The site is Html5/jquerymobile
It contacts what I call a "Wrapper" service.... This is a REST API I wrote in C#, to contact another 3rd party REST API. I do this because there are credentials in the Header and the API uses Basic Authentication. Credentials are therefore not publicized as they are only known server-side.
My "Wrapper" service does not currently implement any additional security. It is currently accessible from anywhere. The easiest and quickest way to lock it down is to restrict by IP, so no other IP anywhere except the server can actually contact my wrapper service.
The questions:
Is the locking by IP the only way to ensure that the API won't get hammered if it was otherwise accessible from anywhere?
If I convert this using Phonegap (which I have... and deployed successfully on Android), obviously the native app won't work if the web service is restricted.
Is there a way around this so I can allow traffic only from the mobile app, and not from any other source? I'm thinking along the lines of MD5 hash or something that could be sent to the wrapper API.. but unfortunately I'm thinking that info can easily be "sniffed".
Is my only viable option here to release the app as a web app, forcing browser use, thereby removing any concerns about allowing my web service to be hammered??
I believe the answer to this is a combination of a user token and encrypting the message through SSL.
The server can issue a valid user a token so we can identify him in future requests.
Encrypting it via SSL will ensure that this token cannot be sniffed.
https://security.stackexchange.com/questions/12531/ssl-with-get-and-post
I have created a simple server accepting tcp and http requests and parsing them in C++. Now I want to create an openID login system which would support Google open ID. I use boost and Curl in my server. Currently I have no ssh in my server except curl can make ssh requests.
So what do I have:
html get/posts requests parsing into maps of map<string, string>
curl with ssh support
file returning server functionality (with modified response arguments)
What else shall I implement to support the possibility of google OpenID login? (I need only some basic unique identifier from user - not his\her name or any other details)
What shall be my steps in order to get unique user ID in server that recieved request with something like openIdLogin :https://www.google.com/accounts/o8/id in it?
I need some simple, readable instructions like once provided by google for reCAPTCHA Verifying the User's Answer Without Plugins - where shall user be redirected, what shall be in Request, Response etc. (not pure Specs)
From the open ID wiki
http://enthusiasm.cozy.org/archives/2005/05/openid-part-iii-pingpong
or from Google's own doc
http://code.google.com/apis/accounts/docs/OpenID.html#Interaction
What it sounds like you are looking for is Google's Federated Login. What it basically amounts to is sending some url requests to Google's servers and providing a callback url where you want the user to return to after they login on Google's servers.
Towards the bottom of the page there are some sample requests and responses that should help you get started.
We currently have a SOAP based web service that our in house applications use to authenticate users. Basically, they send a SOAP request with the username and password. The web service authenticates their credentials against our data store and returns user information if the authentication is successful. The web service is secured using BASIC authentication and SSL.
We need to make modifications to this web service and I was considering re-writing it as a REST service. The REST services I have created in the past have been fairly simple and had no need for security. I have never created a REST service that used sensitive information, so I have a couple of questions / concerns:
First, is there a best practice for sending sensitive query parameters (user credentials) to a REST service securely? I can still use the BASIC authentication and SSL.
Second, if I send a query to a REST service using POST, is it still considered RESTful, or is GET required for REST queries?
You can use SSL and Basic authentication with REST web services as well.
HTTP GET is usually used for data retrieval (queries) but you can use HTTP POST as well. GET is especially useful if you can use any type of HTTP caching. POST is usefull if you need to transfer a lot of data to define your query or if your web service operation expects some complex data format instead of simple arguments.
Instead of doing the authentication via REST, you might also consider a networked authentication protocol to use in conjunction with web services. Technologies like Kerberos and OAuth were designed for these sorts of use cases.
To answer your questions, however:
REST encourages you to leverage HTTP and related protocols, so using SSL and BASIC authentication is quite appropriate.
REST encourages the use of not just GET and POST, but even other HTTP "verbs" such as PUT and DELETE. Use GET only for idempotent operations with no side-effects.
Going from SOAP to REST is taking a step backward as far as security goes.
As far as best practices:
Don't roll your own security. Use a framework or existing library that has been peer-reviewed and tested.
Don't pass unencrypted static keys. If you're using HTTP Basic and sending it across the wire, encrypt it.
Ideally, use hash-based message authentication code (HMAC) because it's the most secure.
Why REST security doesn't exist