Dear Sir/Madam,

We are really struggling to secure the ContextBroker to prevent DELETE
calls. So much that this has become an impediment to successfully finish
our sprint. As Scrum master of this team I would like to ask you kindly to
respond to the e-mail below. An indication of when we can expect a response
would also really be helpful.

We look forward to your response.

I assign this ticket to the AuthZForce owner.

BR

Comment by aalonsog@dit.upm.es :

Hi,

you should contact the AuthZForce owner to solve those questions. I’ve just assigned the corresponding issue to him so he will contact you soon.

I have been informed about your issue installing Authzforce, after Alvaro re-assigned your helpdesk ticket to me.

Could you try installing authzforce-ce-server 5.4.0 by following the latest installation guide?
Link:
http://authzforce-ce-fiware.readthedocs.io/en/release-5.4.0a/
This means using the .deb package (not Docker).
Let me know how it goes.

For the other question regarding Keypass, all I know is what you can find on their github page:
https://github.com/authzforce/server
It is owned by Telefonica (not me/Thales), it is not an official FIWARE GEi since it is not in the FIWARE catalogue. It does not implement the FIWARE Authorization PDP GE API/specification. The features are not much detailed on github, apart from the fact that it provides a multi-tenant REST API to XACML 3.0 PAP/PDP. No info on which part of the XACML Core or which XACML profiles are supported for instance.

On the other hand, Authzforce is the FIWARE Authorization PDP GEri (GE Reference Implementation) and therefore published in the FIWARE catalogue. More info on the FIWARE catalogue:
http://catalogue.fiware.org/enablers/authorization-pdp-authzforce
and on github for the list of features:
https://github.com/authzforce/server

Regards,
Cyril Dangerville, Authorization PDP GE owner

Dear Sir,

We have finally managed to get AuthZForce up and running (despite the fact
it's version 4.4.1b and not the latest version). We used the available
image on Docker Hub. To achieve this we used this guide:
http://authzforce-ce-fiware.readthedocs.io/en/release-4.4.1d/InstallationAndAdministrationGuide.html#domain-creation

We tried linking idm and AuthZForce. These are the steps we took:

• We created a domain in AuthZForce
• In the local_settings.py file in horizon we changed the ACCESS_CONTROL_URL
  to: http://idm.dev.
  babbler.io:8080/authzforce-ce/domains/ZWMqg1NHEea4zwJCrBEAAw/pap/policies
• In our idm app, we created a role and a permission and tried to assign
  the permission to the role, when clicking on the save button we get a page
  full of errors (see .html attachment for the error messages)

The policy does not appear in our
http://idm.dev.babbler.io:8080/authzforce-ce/domains/ZWMqg1NHEea4zwJCrBEAAw/pap/policies
xml tree.
Roles are permissions do get saved in our keystone database,
but apparently can't be linked to each other.

We are stumped and have no idea what's going on.
What are we doing wrong? Hopefully you could shed some light on the
situation. We would appreciate an answer asap, as we would like to get it
working before the end of our sprint.

Met vriendelijke groet/Kind regards,

Hello,
it is an error in IdM, so you may ask the IdM owner (Alvaro in recipient), but I suspect an IdM-Authzforce incompatibility issue. Maybe your IdM version is not compatible with v4.4.1 (old release) of Authzforce. What is your IdM (KeyRock) version?

@Alvaro: could you help on this? Do you see anything useful from the error stacktrace sent previously?

Hi, I also recommend to install latest releases of both components.

Thank you for the reply,

We have upgraded IDM to version 5.3.0 and installed AuthZForce version 5.4.0 manually using the Debian package using this <http://authzforce-ce-fiware.readthedocs.io/en/release-5.4.0/InstallationAndAdministrationGuide.html> guide. We have put the following in Horizon’s local_settings.py:

1. ACCESS CONTROL GE
   ACCESS_CONTROL_URL = 'http://idm.dev.babbler.io:8080/authzforce-ce/domains/A0bdIbmGEeWhFwcKrC9gSQ/pap/policies'
   ACCESS_CONTROL_MAGIC_KEY = None

Although the described error in IDM is no longer occurring, when creating a new role and permissions in IDM, nothing appears to be happening in AuthZForce, not even an error in AuthZForce’s error.log. Are we missing some additional configuration?

Alvaro,
can you confirm that the configuration of ACCESS_CONTROL_URL is correct?
As far as I know, with the latest IdM version, it should be the root URL like:
http://idm.dev.babbler.io:8080?

I just checked openstack_dashboard/fiware_api/access_control_ge.py on
https://github.com/ging/horizon

Regards,
Cyril

Yes, you have to use the root URL.

Hello,
in case you didn't receive Alvaro's reply on JIRA, Alvaro (IdM owner) confirmed that you have to use the root URL for the ACCESS_CONTROL_URL setting, i.e. in your case:

ACCESS_CONTROL_URL = http://idm.dev.babbler.io:8080

Also there was a small API change in the latest Authzforce version (5.4.0). Therefore, you have to change the content of the template file openstack_dashboard/templates/access_control/policy_properties.xacml to this (basically the only change consists to remove the 'ns2' namespace prefix):

<?xml version="1.0" encoding="UTF-8" standalone="yes"?><pdpPropertiesUpdate xmlns="http://authzforce.github.io/rest-api-model/xmlns/authz/5"><rootPolicyRefExpression>{{ policy_id }}</rootPolicyRefExpression></pdpPropertiesUpdate>

--END OF FILE--
That should work. Could you try again with that configuration?

@Alvaro: is there a way to log the requests from KeyRock to Authzforce (and also the responses back)? It would help a lot for troubleshooting.

Kind regards,
Cyril

Dear sirs,

Thank you for your response. I have changed the url like so:

1. ACCESS CONTROL GE
   ACCESS_CONTROL_URL = 'http://idm.dev.babbler.io:8080'
   ACCESS_CONTROL_MAGIC_KEY = None

And changed the contents of policy_properties.xacml to this:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?><pdpPropertiesUpdate xmlns="http://authzforce.gith
ub.io/rest-api-model/xmlns/authz/5"><rootPolicyRefExpression>{{ policy_id }}</rootPolicyRefExpression></p
dpPropertiesUpdate>

And have restarted IDM afterwards.

Next I do the following:
Create a new role in IDM
Create a permission, filling in the HTTP Action (DELETE) and Resource (/test/bla)
Add the permission to the role
Press SAVE

However, I still see only the exact same default domain “A0bdIbmGEeWhFwcKrC9gSQ" with only the default permit-all policy in http://idm.dev.babbler.io:8080/authzforce-ce/domains/A0bdIbmGEeWhFwcKrC9gSQ/pap/policies/root/0.1.0:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns3:PolicySet xmlns="http://authzforce.github.io/core/xmlns/pdp/3.6" xmlns:ns2="http://www.w3.org/2005/Atom" xmlns:ns3="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17" xmlns:ns4="http://authzforce.github.io/rest-api-model/xmlns/authz/5" xmlns:ns5="http://authzforce.github.io/pap-dao-flat-file/xmlns/properties/3.6" PolicySetId="root" Version="0.1.0" PolicyCombiningAlgId="urn:oasis:names:tc:xacml:3.0:policy-combining-algorithm:deny-unless-permit">
<ns3:Target/>
<ns3:Policy PolicyId="permit-all" Version="0.1.0" RuleCombiningAlgId="urn:oasis:names:tc:xacml:3.0:rule-combining-algorithm:deny-unless-permit">
<ns3:Target/>
<ns3:Rule RuleId="permit-all" Effect="Permit"/>
</ns3:Policy>
</ns3:PolicySet>

We still have not seen any sign that the connection between IDM and AuthZForce is working.

Hello Alvaro and Frederico,
regarding issue HELP-6964, in KeyRock, is there a way to log the requests to Authzforce (and also the responses back)? Or any other way to troubleshoot the connection to Authzforce.

We would like to check whether KeyRock is actually connecting to AuthZForce when the user saves the permissions, or why it is failing.

Regards,
Cyril (Authzforce owner)

Dear sirs,

Is there any progress on this issue?

Met vriendelijke groeten,

That worked. We have a bunch of logs now. This is what's happening when
creating a new permission:

Creating permission CRISTANNNNNNN

DEBUG:idm_logger:Creating permission CRISTANNNNNNN

REQ: curl -g -i -X GET http://127.0.0.1:35357/v3/ -H "Accept:
application/json" -H "User-Agent: python-keystoneclient"

2016-08-18 13:57:09.296 18 INFO eventlet.wsgi.server [-] 127.0.0.1 - -
[18/Aug/2016 13:57:09] "GET
/v3/OS-ROLES/users/itude-mobile-dev/organizations/9c4fbe82451b495c9de07596131215e4/applications/allowed_roles
HTTP/1.1" 200 359 0.098138

2016-08-18 13:57:09.300 19 INFO eventlet.wsgi.server [-] 127.0.0.1 - -
[18/Aug/2016 13:57:09] "GET /v3/ HTTP/1.1" 200 484 0.001653

RESP: [200] Vary: X-Auth-Token Content-Type: application/json
Content-Length: 331 Date: Thu, 18 Aug 2016 13:57:09 GMT Connection:
keep-alive

RESP BODY: {"version": {"status": "stable", "updated":
"2013-03-06T00:00:00Z", "media-types": [

,

],
"id": "v3.0", "links": [

]}}

REQ: curl -g -i -X POST http://127.0.0.1:35357/v3/OS-ROLES/permissions -H
"User-Agent: python-keystoneclient" -H "Content-Type: application/json" -H
"Accept: application/json" -H "X-Auth-Token:

3273a540e40bae1953d0f58052b6a06c92441bb5" -d '{"permission": {"xml":
"", "resource": "/test", "name": "CRISTANNNNNNN", "is_internal": false,
"action": "DELETE", "application_id": "fdae7d987c6a435188a2200e31cac4db"}}'

RESP: [201] Vary: X-Auth-Token Content-Type: application/json
Content-Length: 313 Date: Thu, 18 Aug 2016 13:57:09 GMT Connection:
keep-alive

RESP BODY: {"permission": {"xml": "", "resource": "/test", "name":
"CRISTANNNNNNN", "links":

,
"is_internal": false, "action": "DELETE", "application_id":
"fdae7d987c6a435188a2200e31cac4db", "id":
"017f1597bca949069580b54a2a793acf"}}

However, there are no logs with idm.dev.babbler.io (where our Autzforce is
located) even though we have the following set in local_settings.py:

1. ACCESS CONTROL GE

ACCESS_CONTROL_URL = '
http://idm.dev.babbler.io:8080/authzforce-ce/domains/A0bdIbmGEeWhFwcKrC9gSQ/pap/policies
<http://www.google.com/url?q=http%3A%2F%2Fidm.dev.babbler.io%3A8080%2Fauthzforce-ce%2Fdomains%2FA0bdIbmGEeWhFwcKrC9gSQ%2Fpap%2Fpolicies&sa=D&sntz=1&usg=AFQjCNHeGnULlUlkXH2-l_g_5JlceTjcJw>
'

ACCESS_CONTROL_MAGIC_KEY = None

This seems to be the reason why none of the policies are persisted to our
authzforce server.

Also: is ACCESS_CONTROL_MAGIC_KEY required? If yes, what should I set here?
Changing it to 'undefined' like in
https://github.com/ging/fiware-idm/issues/49 doesn't seem to work.

Hi, the magic key is only used if you are securing the AZF with a PEP Proxy. So I guess it is not necessary in your case.

Hello,
I noticed that you are still using an invalid URL for ACCESS_CONTROL_URL (http://idm.dev.babbler.io:8080/authzforce-ce/domains/...) Maybe I was not clear in one of my previous emails, but you should not have the URL path. It should be ACCESS_CONTROL_URL = 'http://idm.dev.babbler.io:8080'

So if the ACCESS_CONTROL_MAGIC_KEY is not necessary, as Alvaro mentioned, can you try again with the following configuration?

ACCESS_CONTROL_URL = 'http://idm.dev.babbler.io:8080'
ACCESS_CONTROL_MAGIC_KEY = 'undefined'

Thanks.

Since it is an issue with the IdM not sending requests to PDP (there is nothing I can do to help on the PDP side), I am re-assigning the ticket to the IDM GE owner.

We've tried both settings. But you're right: the ACCESS_CONTROL_URL should
be 'http://idm.dev.babbler.io:8080'. We've changed it back, and tested
whether it worked by any chance, but it didn't. Here's what we did:

We've changed the setting and restarted idm.

Afterwards, we created a new permission in the dashboard and linked it to a
role (this didn't give any problems, the permission stayed selected) which
uses this IDM. We traced the log (see attachment). Maybe you guys can see
if an error has occured. What's interesting is that there is no evidence
that a call is being made to create a new policy.

Afterwards, we did a call to http://idm.dev.babbler.io:
8080/authzforce-ce/domains/A0bdIbmGEeWhFwcKrC9gSQ/pap/policies

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
> <ns4:resources xmlns="http://authzforce.github.io/core/xmlns/pdp/3.6"
> xmlns:ns2="http://www.w3.org/2005/Atom" xmlns:ns3="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"
> xmlns:ns4="http://authzforce.github.io/rest-api-model/xmlns/authz/5"
> xmlns:ns5="http://authzforce.github.io/pap-dao-flat-file/
> xmlns/properties/3.6">
> <ns2:link rel="item" href="root"/>
> </ns4:resources>

As you can see: no policies can be found even though we created a
permission in the idm application. Also note that A0bdIbmGEeWhFwcKrC9gSQ is
the only domain visible at http://idm.dev.babbler.io:
8080/authzforce-ce/domains/, so we made no mistake there.

Do you have any other suggestions?

Hi Cristian, I need to see the Horizon logs

Closed for inactivity

Dear Technlogy employee,

We are in the process to make the FInish contextbroker more secure. Thus by using the current available technology of FInish.
However the communication seems to fail with Support. We send all information asked and our ticket HELP-6964 is suddenly closed.
The current path is long and time consuming for everyone involved.
Could you help us here to find the right channels to support, so we are able to finalize the last bits of code here ?

Comment by aalonsog@dit.upm.es :

Hi,

last thing I requested in the ticket was the output of the Horizon logs to see what is happening. You need first to configure DEBUG mode in Horizon log settings.

Hello Alvaro Alonso,

Thank you for your reply on our FIWARE issue.
Until now we are honestly convinced we did sent the HORIZON log files in the first place.
So we have been waiting on your analysis on this issue.

If certain settings (such as DEBUG) has to be changed first, please do say so.
(DEBUG was activated).
http://idm.dev.babbler.io:8080/authzforce-ce/domains/A0bdIbmGEeWhFwcKrC9gSQ/pap/policies <http://idm.dev.babbler.io:8080/authzforce-ce/domains/A0bdIbmGEeWhFwcKrC9gSQ/pap/policies>

The debug files are attached.
Could you please reply if this information is sufficient for analyses ?

Renamed attached file: 'Logs IDM:Horizon after creating permission:HTTP.txt rule in IDM' to 'Logs IDM_Horizon after creating permission_HTTP.txt rule in IDM' because it contained invalid character(s).

Hi, I don't see there any logs related the request to AuthZForce. As Cyril said before, we need to see logs with the form:

Access Control Domain for application: XXXXXX

and if it is not created yet:

Access Control Domain not created, creating it...
Domain created: XXXXXXXX

Dear Ilknur, dear FInish FIWARE coach(es),

one of the FInish teams has an issue with securing Orion using AuthZForce (see the two parts marked in green below).
In short they want to prevent DELETE calls to Orion by implementing permissions/rules.

I’m not sure whether using AuthZForce is the correct approach anyway, since only Wilma is mentioned in the Orion documentation:
http://fiware-orion.readthedocs.io/en/develop/user/security/

Do you have an advice?

​Dear Alvaro,

We aren't getting the message: Access Control Domain not created, creating
it...
in our logs. What could be the problem?

Policies are created in AuthZForce when you assign a permission to a role and click in the button "Save". Are you doing this? It seems you are only creating the permission.

I linked a permission to a role and clicked on save to generate the
rule/policy but do not see what you describe in my logs (these are the logs
we previously sent up).
I do see:
ACCESS_CONTROL_MAGIC_KEY setting is not set.
WARNING:idm_logger:ACCESS_CONTROL_MAGIC_KEY setting is not set.

Met vriendelijke groet/Kind regards

Just to be sure:
Do we need to configure a Wilma PEP proxy and specify the Authorization PDP
GE URL in the config file? We are only configuring IDM with the AuthZForce
service.
Because we don't specific a our AuthZForce domain maybe the system doesn't
know where to write the policy? I saw that we do have to define this in the
PEP config file if we were to use this in combination with IDM and the
AuthZForce service.

Met vriendelijke groet/Kind regards,

Hi,

you have to use your own AuthZForce instance an set its address in Horizon configuration. PEP Proxy is not necessary.

Hello Help-Desk/Alvaro Alonso,

Thank you for your reply and possibile fixes. Unfortunately it still does not work yet.
To move forward on the security, we have decided to change our software-architecture.
In this new architecture we do not need to secure the Contextbroker anymore since it will listen to our local API only.
I would like to thank you al for the support on this issue. From our perspective, you may close this issue.