I have to think about an architecture using FIWARE orion context-broker and several IoT agents/context-provider. In the documentation is a section describing how to securue the communication from an IoT agent/context-provider to orion. But how to secure the other sider?
What I understand, so far, is that a context-provider has to expose a REST endpoint (/op/query) on which it accepts incomming traffic. But how do it can make sure, that these request are valid?
In case of a subscription you can use httpCustom instead of http in the provider section, when you create a subscription. With this it is possible to use a static token which will be used by orion, when making request to the given url. This isn't possible for registration. Any suggestions how a context-provider/IoT agent can decide if an incoming request is a valid one?
With NGSIv2 Subscription/Notification and Register/Forwarding you will receive an X-Auth-Token Header with the token used in the initial update operation. You should be able to check within the IDM (Keystone in our Stack).
As a workaround you may use the value itself to send some kind of Apikey along with the real value.
Network security may apply also, it is common to use firewalls and restrict ip/ports, or stablish APN/VPN at distributed architectures (at least with unsecured devices or external networks).
Last, if synchronous communication is not a must for your use case (registers are sync, sub/notif are async), it is not a big deal to use Subs/Notif mechanism to communicate with a Context Adapter. We do sometimes, registers are tricky and troublesome.
Best.
Related
We are evaluating several platforms for integrating a "Smart Energy System".
One important requirement we have to support is multitenancy. From the docs I can see the possibility to start the Orion Context Broker with this option. Orion will ensure the data separation based on the fiware-service request header.
That's fine but how to "secure" this header across the whole software stack (PEP-Proxy, IoT-Agent)?
Which component/device sets this header? Which component ensures that a request with a specific fiware-service header value is authorized to access the data of this tenant?
In my opinion this is a task for Wilma as PEP-Proxy. All traffic to Orion is routed through the PEP-Proxy and the proxy checks if this request is valid. Unfortunately I can not find such a check within the source code nor it is explained in the documentation.
Has someone implemented such an architecture an can help me?
Found another post which answers my question
How to configure access control in Orion NGSI API for tenant isolation using Wilma PEP Proxy and IdM Keyrock?
We will have to implement this kind of authorization for our own.
I am studying websocket RFC 6455 where the security model of web-socket is stated to be origin-based security model . As well it is mentioned that this security model is used by web browsers. So what is this origin-based security model about?
CORS does not apply to WebSocket. A page JS can connect to any WebSocket server. It's just that browser WebSocket clients will send an origin header, which you may or may not use in your server to deny the client. However, non-browser clients can fake that, so it's of limited use.
Essentially, data/script is classified as trusted or not based on where it's loaded from, if you know about same origin policy or cross origin resource sharing (CORS) then you know that browsers puts some restrictions on Javascript that is loaded from different domains.
What happens:
Client connects to Server, setting up TCP connection with HTTP layered on top.
In case of HTTPS, there is also an agreement on the cryptographic protocol to use, a key exchange and possibly a certificate exchange. If a certificate exchange happens:
Client may ascertain that the Server is what it pretends it is by verifying the certificate of the Server using the public key of the Server (generally done tp make sure there is no man-in-the-middle attack going on or DNS spoofing is happening etc.)
Server may ascertain that the Client is what it pretends it is by verifying the certificate of the Client using the public key of the Client (only done in cases where the use case demands that the Client identity is important)
Connection is established! From here on, anything that goes over the TCP connection is considered healthy. "Going over the connection" means "same origin": It comes from the same client (or it comes from the same server).
It might well be that there is an evil hack on the client (or even the server) that borks the existing connection on the TCP or HTTP level and injects its own packets, data, requests or XML blocks. Too bad! There is no way this can be precluded in the described approach. One would need to have additional checks on the protocol, e.g. have a separate signature on each individual request signed by mutually trusted hardware modules installed by ${company representative} or something similarly complex.
Hoping someone can remedy my naivety when it comes to calling a simple URL to an application (which returns XML) using NTLMv2.
I have read pretty much every question and page there is but I am left with one overriding curiosity. I am using the HTTPClient at present (although this can be changed) along with the latest JDK (at the time of writing).
Here is an example page which appears to call the JCIFS library:
http://hc.apache.org/httpcomponents-client-ga/ntlm.html
All looks good, albeit confusing, but this highlights the question that many of the examples I have seen raises - the issue of supplying NTCredentials.
To me the whole point of NTLM is so that I do not have to supply credentials. The target aplication is set up to use NTLM so surely the user credntials of the currently logged in user should be used? Why should I be supplying any credentials myself?
Apologies if I am missing something obvious here. I just need the most basic for of NTLM SSO possible using Java. I don't care what version of what, I am able to use the latest of anything.
Holding out hope! Thanks for reading.
Unfortunately, there's way to do single sign-on in a pure Java environment.
NTLM isn't a solution to single sign-on directly. NTLM is a challenge/response authentication mechanism and it requires the NTLM hash of the user's password. Windows machines are able to provide single sign-on using NTLM because the NTLM hash is persisted. They are then able to compute the response to a challenge based on the persisted hash.
Without access to that hash (and, to my knowledge, you can't simply request it) you need to compute it yourself. And that requires having the user's password.
Similarly, you can do single sign-on with a Kerberos ticket using SPNEGO authentication (if the remote system is setup to support it, of course) but Java unfortunately reimplemented Kerberos instead of using the system Kerberos libraries. So even if you were already logged in to the domain, you'd need to go get another Kerberos ticket for Java. And that means typing your password in again.
The only realistic way to avoid typing in a password to authenticate is to call the native methods. On Windows, this is SSPI, which will provide you the ability to respond to an NTLM or SPNEGO challenge. On non-Windows platforms, this is handled by the very similar GSSAPI and provides the ability to respond to SPNEGO (Kerberos).
What is the difference between a simple Async servlet and the Comet / Bayeux protocol?
I am trying to implement a "Server Push" (or "Reverse Ajax") kind of webpage that will receive updates from the server as and when events occur on the server. So even without the client explicitly sending a request, I need the server to be able to send responses to the specific client browser.
I understand that Comet is the umbrella term for these kind of technologies; with 'Bayeux' being the protocol. But when I looked through the servlet spec, even the 'Async servlet' seems to accomplish the same thing. I mean I can define a simple servlet with the
<async-supported>
attribute set to true in the web.xml; and that servlet will be able to asynchronously send responses to the client. I can then have a jQuery or ExtJS based ajax client that just keeps doing a
long_polling()
call into the servlet. Something like what is described in the link below
http://www.ibm.com/developerworks/web/library/wa-reverseajax1/index.html#long
So my question is this:
What is the difference between a simple Async servlet and the Comet / Bayeux protocol?
Thanks
It is true that "Comet" is the term for these technologies, but the Bayeux protocol is used only by few implementations. A Comet technique can use any protocol it wants; Bayeux is one of them.
Having said that, there are two main differences between an async servlet solution and a Comet+Bayeux solution.
The first difference is that the Comet+Bayeux solution is independent of the protocol that transports Bayeux.
In the CometD project, there are pluggable transports for both clients and servers that can carry Bayeux.
You can carry it using HTTP, with Bayeux being the content of a POST request, but you can also carry it using WebSocket, with Bayeux being the payload of the WebSocket message.
If you use async servlets, you cannot leverage WebSocket, which is way more efficient than HTTP.
The second difference is that async servlets only carry HTTP, and you need more than that to handle remote Comet clients.
For example, you may want to identify uniquely the clients, so that 2 tabs for the same page result in 2 different clients. To do this, you need add a "property" to the async servlet request, let's call it sessionId.
Next, you want to be able to authenticate a client; only authenticated clients can get a sessionId. But to differentiate between first requests to authenticate and others subsequent requests already authenticated, you need another property, say messageType.
Next, you want to be able to notify quickly disconnections due to network loss or other connectivity problems; so you need to come up with a heart-beat solution so that if the heart beats you know the connection is alive, if it does not beat you know it's dead, and perform rescue actions.
Next you need disconnect features. And so on.
Quickly you realize that you're building another protocol on top of HTTP.
At that point, it's better to reuse an existing protocol like Bayeux, and proven solutions like CometD (which is based on Comet techniques using the Bayeux protocol) that gives you:
Java and JavaScript client libraries with simple yet powerful APIs
Java server library to perform your application logic without the need to handle low level details such as HTTP or WebSocket via annotated services
Transport pluggability, both client and server
Bayeux protocol extensibility
Lazy messages
Clustering
Top performance
Future proof: users of CometD before the advent of WebSocket did not change a line of code to take advantage of WebSocket - all the magic was implemented in the libraries
Based on standards
Designed and maintained by web protocols experts
Extended documentation
I can continue, but you get the point :)
You don't want to use a low-level solution that ties you to HTTP only. You want to use a higher level solution that abstracts your application from the Comet technique used and from the protocol that transports Bayeux, so that your application can be written once and leverage future technology improvements. As an example of technology improvement, CometD was working well way before async servlets came into picture, and now with async servlet just became more scalable, and so your application, without the need to change a single line in the application.
By using a higher level solution you can concentrate on your application rather than on the gory details of how to write correctly an async servlet (and it's not that easy as one may think).
The answer to your question could be: you use Comet+Bayeux because you want to stand on the shoulder of giants.
I'm looking for an easy way to implement the XMPP server running with the following protocol:
https://developers.google.com/cloud-print/docs/rawxmpp
The only difference is that I must use X-GOOGLE-TOKEN authentication mechanism: https://stackoverflow.com/a/6211324/227244
The procedure is simple: I get the token from the data sent by a client, request user data based on this token and set the JID accordingly, appending some random chars to the resulting JID.
After that other clients with possibly different tokens, but same user account, connect to the XMPP resource and for clients who are subscribed the broadcast of push notifications is enabled.
What amount of the server code can be borrowed from the currently available implementations? I would avoid writing all of the server code myself, though the logic is pretty simple. I know there're ejabberd and prosody xmpp servers which implement lots of XEP. Which one is easier to add the custom handling mechanism to? Can you suggest other stable alternatives for the core xmpp server?
The way google has designed X-OAUTH2 is dead simple and straightforward to implement. Infact, there is no difference between how PLAIN and X-OAUTH2 mechanisms work. You can simply pick a standard PLAIN implementation and make it work for google X-OAUTH2 authentication mechanism with no extra effort.
I am author of Jaxl PHP library and I recently announced support for X-OAUTH2 inside the library. Here you can see exact lines of code I had to write to support this. The only relevant piece of code is:
switch($mechanism) {
case 'PLAIN':
case 'X-OAUTH2':
$stanza->t(base64_encode("\x00".$user."\x00".$pass));
break;
For X-OAUTH2 implementation $pass is nothing but your oauth token. In short, password field from PLAIN auth mechanism becomes oauth token for X-OAUTH2 mechanism. Rest all remains the same.