I have in my server a Orion Context Broker (https://github.com/telefonicaid/fiware-orion) but i need to add some restrictions to my "consumers" when they use the endpoint(s) e.g(http://myhost:1026/v2/entities). Is possible configure the local/personal Broker with token like https://fiware-orion.readthedocs.io/en/1.11.0/quick_start_guide/index.html#orion-context-broker-quick-start-guide ?
Thank you very much.
The Orion Context Broker does not offer roles and permissions directly.
To add roles and permissions to restrict an endpoint, you will need to use a PEP Proxy - which security mechanism you use to do this is up to you.
There are several OAuth2-based security components found within the FIWARE Catalogue, alternatively you could another open source PEP Proxy such as steelskin which integrates nicely with either Keyrock or Keystone
Related
First of all, I'm using the Telefonica implementations of Identity Manager, Authorization PDP and PEP Proxy, instead of the Fiware reference implementations which are Keyrock, AuthZForce and Wilma PEP Proxy. The source code and reference documentation of each component can be found in the following GitHub repos:
Telefonica keystone-spassword:
GitHub /telefonicaid/fiware-keystone-spassword
Telefonica keypass:
GitHub /telefonicaid/fiware-keypass
Telefonica PEP-Proxy:
GitHub /telefonicaid/fiware-pep-steelskin
Besides, I'm working with my own in-house installation of the components, NO Fi-Lab. In addition to security components, I've an IoT Agent-UL instance and an Orion Context Broker instance.
Starting from that configuration, I've created a domain in keystone (Fiware-Service) and a project inside the domain (Fiware-ServicePath). Then I've one device connected to the platform, sendding data to the IoT Agent behind the PEP Proxy. The whole device message is represented as a single Entity in Orion Context Broker.
So, the question is:
How can I restrict a specific keystone user to access only to the entity associated to this device, at the level of the Orion Context Broker API?
I know that I can allow/deny user acces to specific API via keystone Roles and XACML Policies but that implies that I should create one Policy per User-Device pair.
I could use some help with this, to know if I'm on the right way.
I do not think Access Control can be done to Orion without Security GEs. Each GE has a specific purpose and access control is not one of the Orion's purposes.
As stated in the Security Considerations from Orion documentation:
Orion doesn't provide "native" authentication nor any authorization mechanisms to enforce access control. However, authentication/authorization can be achieved the access control framework provided by FIWARE GEs.
Also, there is something related in another link:
Orion itself has no security. It’s designed to be run behind a proxy server which provides security and access control. Used within the FIWARE Lab, they run another service build on node.js, “PEP Proxy Wilma”, in front of it. Wilma checks that you have obtained a token from the FIWARE lab and put it in the headers.
Besides, the link below can endorse my opinion about Orion and access control:
Fiware-Orion: Access control on a per subscription basis
My opinion is that you are in the right way using the other security components.
About "create one Policy per User-Device pair" as you mention, maybe it would be better you thought about "group policies" instead.
Can the Fiware enabler AuthZforce be used without keyrock and wilma?
can it be used using others pep and IDM?
Yes, it can. The AuthZForce API is not designed specifically for KeyRock/Wilma. Just to clarify, KeyRock consumes the PAP API of AuthZForce, and Wilma consumes the PDP API of AuthZForce. To achieve that, the KeyRock/Wilma team have developed their own AuthZForce API connectors, i.e. the client part that consumes AuthZForce API. So if you use another PEP/IdM, you have to develop a similar connector for this particular PEP/IdM, if it is not already there. A the end of the user guide, we give some hint to help develop your own Authzforce API client. In any case, all you need is a good HTTP/REST/XML framework to start with.
Regards,
Cyril
We want to use the FIWARE IdM, both Keystone and Horizon. Specifically during sign-up we want to
create a user
add that user to an organisation
authorise the user for an application
We have installed Keystone and Horizon using the latest KeyRock docker image on the docker hub.
When a new user signs up:
a 'cloud organisation' is created.
By default, the 'provider' and 'purchaser' roles are present
and the 'Store' application is assigned to the user (although i cannot verify this).
We can add the user to an organisation by hand, and authorise the user for an application by hand in the KeyRock UI.
However this does not make any sense for our local installation.
How can we prevent Horizon from creating the cloud organisation upon user sign-up?
How can we assign a default application authorization upon user sign-up?
-- Edit --
It’s becoming increasingly clear to me that the way KeyRock is implemented is primarily useful for setting up your own Fiware labs environment, as opposed to setting up a generic Identity management service. If we use KeyRock, we will be stuck with cloud organisations, stores etc. Far from being a Generic Enabler (GE), KeyRock seems to be a “Fiware Labs” specific enabler.
All the GE documentation references KeyRock as the reference Identity Management GE. Therefore we (and i assume others too) have followed the documented architecture and configuration to link to KeyRock from:
Wilma PEP Proxy GE
Wirecloud Application Mashup GE
Because of the inbuilt Fiware Labs functions of KeyRock, we are having a really hard time applying Wilma PEP Proxy and Wirecloud Application Mashup to our use cases.
If we decide to use Keystone instead, we will lose
OAuth2 support
Permissions
sign-up, admin and login screens.
Is anyone else having this problem?
How have they tackled it?
-- SCIM API --
Attempt at using the SCIM API is described here: Fiware KeyRock SCIM API bug: _check_allowed_to_get_and_assign() got an unexpected keyword argument 'userName'
I'm deploying some Generic Enablers(Orion, Cygnus, Proton-Cep, Wirecloud) in the same VM using dockers.
Reading the fiware documentation it uses has an example a wilma proxy securing an instance of orion and getting the authorization through IdM.
Wilma configurations do not seem to support different redirections
I need to secure all these services that I'm using which need to be accessed from outside the server, my question is if is it possible to use Wilma to secure all Generic Enablers or should I implement one instance of Wilma for each service provided?
How can we secure the communication between Orion and Cygnus?
How can we use cygnus with a protected Orion (pep is deployed above Orion broker)?
Thanks and best regards.
There are several ways of securing Orion->Cygnus communications:
Co-locate Orion and Cygnus in the same host, so all comunication are through localhost network interface (this solution assumes that the host itslef is properly secured, of course).
Using a firewall (e.g. iptables) so Cygnus port can be reached only from the IP where Orion runs.
Using HTTPS notifications. In order to use this option take into account that:
Cygnus should be able to receive notifications in HTTPS. I'm not fully sure about Cygnus capabilities with this regards, but my colleague #frb could provide more detail.
You need Rush to send notifications in HTTPS with Orion.
You can also explore the posibility of using a PEP proxy for Cygnus. You only need to secure one operation at Cygnus: POST /v1/notifyContext. Have a look to the PEP official documentation.
UPDATE: since verion 1.7.0, Orion implements native HTTPS notifications (i.e. without needing Rush).