3

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.

Emiliano Viotti
  • 1,619
  • 2
  • 16
  • 30

1 Answers1

1

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.

Community
  • 1
  • 1
Dalton Cézane
  • 3,672
  • 2
  • 35
  • 60
  • I did not say that the Orion Context Broker provide Access Control. In fact It does not! For that purposes exists the security GEs (PEP Proxy, Identity Manager and Authorization PDP) as you mentioned. How ever exists two diferent implementations of the same three GEs. Also there is a not very exhaustive post on stack overflow http://stackoverflow.com/questions/36920783/fiware-wilma-vs-steelskin about the diferences between Wilma PEP-Proxy and Steelskin PEP Proxy. – Emiliano Viotti May 11 '17 at 11:41
  • I chosed Telefonica implementation of the three GEs, because GING implementations seems have specific extensions for Fi-Lab. But may be I am in the wrong way. Actually, what I fear is that based on the implementations of Telefonica at least, there does not seem to be a natural way to implement the type of access control I propose. Based on your response and activity I see that you have some experience using the GING implementations (Wilma PEP Proxy, etc). You could tell me if the implementation of GING is better for some reason, or in some particular scenario? Thanks! – Emiliano Viotti May 11 '17 at 11:44
  • 1
    Hello, @Emiliano . Related to your question, my answer was `My opinion is that you are in the right way using the other security components.` Unfortunately I just used the Security GEris (Keyrock, Wilma and just a bit of AuthZForce). I did not use the Security components you are using, so I cannot explain the main differences between both. Currently, I am prefering use the GEris (GE reference implementations) just because they are the "references". =) And, to avoid many individual policies, I would think in a group policies approach. – Dalton Cézane May 11 '17 at 15:34