Details
-
Type:
extRequest
-
Status: Closed
-
Priority:
Major
-
Resolution: Done
-
Fix Version/s: 2021
-
Component/s: FIWARE-TECH-HELP
-
Labels:None
-
HD-Chapter:Security
-
HD-Enabler:Wilma
Description
Dear Sirs,
We have the current architecture:
- Own Keyrock instance (server 1) - Ubuntu
- Orion ContextBroker service (running on server 2) - CentOS
- PEP Proxy that redirects to our own API (server 2) - CentOS
It is currently possible to make HTTP calls such as DELETE attribute/entity
directly to the Context Broker using any API testing tool, such as Postman.
We want to prohibit this.
We have some trouble understanding how to go about this.
This is what we think needs to be done:
1. Create a PEP Proxy for ContextBroker app in Idm
2. Configure a PEP Proxy on server 2 (and run next to the current PEP
Proxy that we already have)
3. Create a new role and permission (HTTP verb and resource URL) in the
PEP Proxy for ContextBroker
4. Link the two (this is by default not possible, however, the
individual role and permission are created in the Keystone database)
5. Assign the role to a user (or perhaps an organization?)
6. Install and configure a AuthZForce server which deals with the
configured permissions in Idm and transforms them to XACML
We would like to know if this is the correct way to achieve prohibiting
certain calls to the Context Broker.
Our questions are:
- How can we run a second PEP Proxy next to our already existing PEP
Proxy on the same server? PEP Proxy 1 is configured in config.js and PEP
Proxy 2 (for the Context Broker) is configured in config_context_broker.js
(see config file attached to this e-mail) - Does Idm already have a default AuthZForce server, if so, how can we
activate it? - Why can't we link a role to a permission in the user interface
(perhaps this is because the AuthZForce server is not yet implemented?) - How can we configure the PEP Proxy for ContextBroker to work with
AuthZForce? - How can we configure AuthZForce?
- How can we prohibit certain calls for non-FIWARE users (random people
that make the calls)?, are the rules only applicable to FIWARE users?
Hopefully you guys can shed some light on the situation or forward this
e-mail to the relevant contact person responsible for PEP Proxy, Orion
Context Broker or AuthZForce. We hope you will get back to us asap. Thanks
in advance. I also attached an example of a call that can be made to our
Context Broker to change data.
Activity
| Field | Original Value | New Value |
|---|---|---|
| Component/s | FIWARE-TECH-HELP [ 10278 ] |
| HD-Enabler | Unknown [ 10910 ] | |
| HD-Chapter | Unknown [ 10845 ] | |
| HD-Node | Unknown [ 10852 ] |
| HD-Enabler | Unknown [ 10910 ] | Wilma [ 10890 ] |
| HD-Chapter | Unknown [ 10845 ] | Security [ 10841 ] |
| Assignee | Alvaro Alonso [ aalonsog ] |
| Status | Open [ 1 ] | In Progress [ 3 ] |
| Status | In Progress [ 3 ] | Answered [ 10104 ] |
| Resolution | Done [ 10000 ] | |
| Status | Answered [ 10104 ] | Closed [ 6 ] |
| Summary | [Fiware-tech-help] Question about prevention of certain calls to Orion Context Broker using HTTP Verb and Resource in Idm | FIWARE.Request.Tech.Security.PEP-Proxy.Question about prevention of certain calls to Orion Context Broker using HTTP Verb and Resource in Idm |
| HD-Node | Unknown [ 10852 ] |
| External Participants | s.vos@itude.com,e.bon@itude.com | s.vos@itude.com,jsalvachua@dit.upm.es,e.bon@itude.com |
| Sender Email | k.patenaude@itude.com | k.patenaude@itude.com,aalonsog@dit.upm.es |
I already answered this question in the Help desk question you opened.
Show
FW External User
added a comment - - edited I already answered this question in the Help desk question you opened.
| Sender Email | k.patenaude@itude.com,aalonsog@dit.upm.es |
| External Participants | s.vos@itude.com,jsalvachua@dit.upm.es,e.bon@itude.com |
| Description |
Dear Sirs, *We have the current architecture:* - Own Keyrock instance (server 1) - Ubuntu - Orion ContextBroker service (running on server 2) - CentOS - PEP Proxy that redirects to our own API (server 2) - CentOS It is currently possible to make HTTP calls such as DELETE attribute/entity directly to the Context Broker using any API testing tool, such as Postman. We want to prohibit this. We have some trouble understanding how to go about this. *This is what we think needs to be done:* 1. Create a PEP Proxy for ContextBroker app in Idm 2. Configure a PEP Proxy on server 2 (and run next to the current PEP Proxy that we already have) 3. Create a new role and permission (HTTP verb and resource URL) in the PEP Proxy for ContextBroker 4. Link the two (this is by default not possible, however, the individual role and permission are created in the Keystone database) 5. Assign the role to a user (or perhaps an organization?) 6. Install and configure a AuthZForce server which deals with the configured permissions in Idm and transforms them to XACML We would like to know if this is the correct way to achieve prohibiting certain calls to the Context Broker. *Our questions are:* - How can we run a second PEP Proxy next to our already existing PEP Proxy on the same server? PEP Proxy 1 is configured in config.js and PEP Proxy 2 (for the Context Broker) is configured in config_context_broker.js (see config file attached to this e-mail) - Does Idm already have a default AuthZForce server, if so, how can we activate it? - Why can't we link a role to a permission in the user interface (perhaps this is because the AuthZForce server is not yet implemented?) - How can we configure the PEP Proxy for ContextBroker to work with AuthZForce? - How can we configure AuthZForce? - How can we prohibit certain calls for non-FIWARE users (random people that make the calls)?, are the rules only applicable to FIWARE users? Hopefully you guys can shed some light on the situation or forward this e-mail to the relevant contact person responsible for PEP Proxy, Orion Context Broker or AuthZForce. We hope you will get back to us asap. Thanks in advance. I also attached an example of a call that can be made to our Context Broker to change data. Met vriendelijke groet/Kind regards, *Kirstie Patenaude* Mobile Software Engineer Lageweg 2 3703 CA Zeist ■ *Mob:* +31(0)6 51 13 56 18 ■ *Tel. receptie:* +31(0)30 699 70 20 ■ *Mail:* k.patenaude@itude.com www.itude.com ■ K.v.K. 30146090 Since January 1st, old domains won't be supported and messages sent to any domain different to @lists.fiware.org will be lost. Please, send your messages using the new domain (Fiware-tech-help@lists.fiware.org) instead of the old one. _______________________________________________ Fiware-tech-help mailing list Fiware-tech-help@lists.fiware.org https://lists.fiware.org/listinfo/fiware-tech-help [Created via e-mail received from: Kirstie Patenaude <k.patenaude@itude.com>] |
Dear Sirs,
*We have the current architecture:* - Own Keyrock instance (server 1) - Ubuntu - Orion ContextBroker service (running on server 2) - CentOS - PEP Proxy that redirects to our own API (server 2) - CentOS It is currently possible to make HTTP calls such as DELETE attribute/entity directly to the Context Broker using any API testing tool, such as Postman. We want to prohibit this. We have some trouble understanding how to go about this. *This is what we think needs to be done:* 1. Create a PEP Proxy for ContextBroker app in Idm 2. Configure a PEP Proxy on server 2 (and run next to the current PEP Proxy that we already have) 3. Create a new role and permission (HTTP verb and resource URL) in the PEP Proxy for ContextBroker 4. Link the two (this is by default not possible, however, the individual role and permission are created in the Keystone database) 5. Assign the role to a user (or perhaps an organization?) 6. Install and configure a AuthZForce server which deals with the configured permissions in Idm and transforms them to XACML We would like to know if this is the correct way to achieve prohibiting certain calls to the Context Broker. *Our questions are:* - How can we run a second PEP Proxy next to our already existing PEP Proxy on the same server? PEP Proxy 1 is configured in config.js and PEP Proxy 2 (for the Context Broker) is configured in config_context_broker.js (see config file attached to this e-mail) - Does Idm already have a default AuthZForce server, if so, how can we activate it? - Why can't we link a role to a permission in the user interface (perhaps this is because the AuthZForce server is not yet implemented?) - How can we configure the PEP Proxy for ContextBroker to work with AuthZForce? - How can we configure AuthZForce? - How can we prohibit certain calls for non-FIWARE users (random people that make the calls)?, are the rules only applicable to FIWARE users? Hopefully you guys can shed some light on the situation or forward this e-mail to the relevant contact person responsible for PEP Proxy, Orion Context Broker or AuthZForce. We hope you will get back to us asap. Thanks in advance. I also attached an example of a call that can be made to our Context Broker to change data. |
| Fix Version/s | 2021 [ 12600 ] |
| Transition | Time In Source Status | Execution Times | Last Executer | Last Execution Date | |||||
|---|---|---|---|---|---|---|---|---|---|
|
1d 22h | 1 | Alvaro Alonso | 13/Jul/16 9:15 AM | |||||
|
2s | 1 | Alvaro Alonso | 13/Jul/16 9:15 AM | |||||
|
1s | 1 | Alvaro Alonso | 13/Jul/16 9:15 AM |
Hi, I try to answer the questions related with Wilma and Keyrock: