[ https://jira.fiware.org/browse/HELP-6895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Fernando Lopez updated HELP-6895:
---------------------------------
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.
was:
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 at 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 at lists.fiware.org) instead of the old one.
_______________________________________________
Fiware-tech-help mailing list
Fiware-tech-help at lists.fiware.org
https://lists.fiware.org/listinfo/fiware-tech-help
[Created via e-mail received from: Kirstie Patenaude <k.patenaude at itude.com>]
> FIWARE.Request.Tech.Security.PEP-Proxy.Question about prevention of certain calls to Orion Context Broker using HTTP Verb and Resource in Idm
> ---------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: HELP-6895
> URL: https://jira.fiware.org/browse/HELP-6895
> Project: Help-Desk
> Issue Type: extRequest
> Components: FIWARE-TECH-HELP
> Reporter: FW External User
> Assignee: Alvaro Alonso
> Attachments: Append_call_example.rtf, contextBroker_Pep_config.rtf
>
>
> 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.
--
This message was sent by Atlassian JIRA
(v6.4.1#64016)
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy