Uploaded image for project: 'Help-Desk'
  1. Help-Desk
  2. HELP-6895

FIWARE.Request.Tech.Security.PEP-Proxy.Question about prevention of certain calls to Orion Context Broker using HTTP Verb and Resource in Idm

    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.

      1. contextBroker_Pep_config.rtf
        2 kB
        FW External User
      2. Append_call_example.rtf
        1 kB
        FW External User

        Activity

        fla Fernando Lopez made changes -
        Fix Version/s 2021 [ 12600 ]
        fla Fernando Lopez made changes -
        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.
        fla Fernando Lopez made changes -
        fla Fernando Lopez made changes -
        backlogmanager Backlog Manager made changes -
        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 ]
        aalonsog Alvaro Alonso made changes -
        Resolution Done [ 10000 ]
        Status Answered [ 10104 ] Closed [ 6 ]
        aalonsog Alvaro Alonso made changes -
        Status In Progress [ 3 ] Answered [ 10104 ]
        aalonsog Alvaro Alonso made changes -
        Status Open [ 1 ] In Progress [ 3 ]
        backlogmanager Backlog Manager made changes -
        Assignee Alvaro Alonso [ aalonsog ]
        backlogmanager Backlog Manager made changes -
        HD-Chapter Unknown [ 10845 ] Security [ 10841 ]
        mev Manuel Escriche made changes -
        HD-Enabler Unknown [ 10910 ] Wilma [ 10890 ]
        backlogmanager Backlog Manager made changes -
        HD-Enabler Unknown [ 10910 ]
        HD-Chapter Unknown [ 10845 ]
        HD-Node Unknown [ 10852 ]
        backlogmanager Backlog Manager made changes -
        Field Original Value New Value
        Component/s FIWARE-TECH-HELP [ 10278 ]
        fw.ext.user FW External User created issue -

          People

          • Assignee:
            aalonsog Alvaro Alonso
            Reporter:
            fw.ext.user FW External User
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: