[Fiware-tech-help] [FIWARE-JIRA] (HELP-6895) Question about prevention of certain calls to Orion Context Broker using HTTP Verb and Resource in Idm

[Backlog Manager (JIRA)]

     [ https://jira.fiware.org/browse/HELP-6895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Backlog Manager reassigned HELP-6895:
-------------------------------------

    Assignee: Alvaro Alonso

> [Fiware-tech-help] 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.
> 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>]



--
This message was sent by Atlassian JIRA
(v6.4.1#64016)