>From FIWARE JIRA - Main Help Desk ----
-------------------------------------------------------------------------------
Comments:
FW External User - Today 12:59 PM
------------------
Comment by k.patenaude at itude.com :
Dear Alvaro,
We aren't getting the message: Access Control Domain not created, creating
it...
in our logs. What could be the problem?
Met vriendelijke groet/Kind regards,
*Kirstie Patenaude*
Mobile Software Engineer
HNK-CS
Arthur van Schendelstraat 650
3511 MJ Utrecht
■ *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
On Mon, Sep 19, 2016 at 4:25 PM, Help-Desk <jira-help-desk at fi-ware.org>
wrote:
>
>
FW External User - Yesterday 4:33 PM
------------------
Comment by einramhof at atb-bremen.de :
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?
Kind regards,
Peter on behalf of FInish.
***FROM ONE OF THE PREVIOUS EMAILS***
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.
Von: Simon Vos [mailto:s.vos at itude.com]
Gesendet: Montag, 19. September 2016 15:23
An: Peter Einramhof <einramhof at atb-bremen.de<mailto:einramhof at atb-bremen.de>>
Cc: FInish-Technology at FInish-Project.eu<mailto:FInish-Technology at FInish-Project.eu>
Betreff: Re: [FInish-Technology] Help on issue HELP-6964
Dear Peter,
We have also sent an email to FIWARE JIRA (Avaro Alonso is involved here).
Indeed we are trying to use HORIZON/IDM to implement http verb-rules to secure the contexbroker by allowing specific calls to the contextbroker.
Creating the rules still fails.
We have not yet tried to implement this by adding an extra PEP-Proxy.
Summary until now:
- We installed the AuthZForce service on our IDM instance
- We tried to create HTTP verb rules (permission) in IDM.
- In IDM we see that the permissions has successfully created
- Linking a role to this permission has succeeded as well.
- However this permission is not visible in AuthZForce when doing a call doing a request-tool
- In the IDM log we saw a message stating “…failed to create policy in AuthZForce…”.
Hope you will be able to help us further quickly.
If you will need more information, please reply.
Kind regards,
Simon Vos
[cid:image001.png at 01D21293.559CAF30]
Arthur van Schendelstraat 650
3511 MJ Utrecht
■ mob +31(0) 6 21 49 93 82
■ tel receptie +31(0)30 699 70 20
■ mail s.vos at itude.com<mailto:s.vos at itude.com>
■ linkedIn linkedin.com/in/simonvos<https://linkedin.com/in/simonvos>
www.itude.com<http://www.itude.com/> ■ K.v.K. 30146090
Alvaro Alonso - Yesterday 4:24 PM
------------------
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
FW External User - Yesterday 4:08 PM
------------------
Comment by s.vos at itude.com :
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).
FW External User - Yesterday 4:08 PM
------------------
Comment by s.vos at itude.com :
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 ?
Kind Regards, Simon Vos
> Op 19 sep. 2016, om 09:37 heeft Help-Desk <jira-help-desk at fi-ware.org> het volgende geschreven:
>
>
>
FW External User - Yesterday 9:36 AM
------------------
Comment by aalonsog at 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
--
Álvaro
> El 16 sept 2016, a las 16:17, Simon Vos <s.vos at itude.com> escribió:
>
> 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 ?
>
> Kind Regards,
>
>
> Simon Vos
>
>
> <PastedGraphic-2.png>
> Arthur van Schendelstraat 650
> 3511 MJ Utrecht
> ■ mob +31(0) 6 21 49 93 82
> ■ tel receptie +31(0)30 699 70 20
> ■ mail s.vos at itude.com <mailto:s.vos at itude.com>
> ■ linkedIn linkedin.com/in/simonvos <https://linkedin.com/in/simonvos>
>
>
> www.itude.com <http://www.itude.com/> ■ K.v.K. 30146090
> _____________________________________________________________________________
> ***Op deze mail is een disclaimer van toepassing. De inhoud daarvan is te lezen op onze website***
>
>> Begin doorgestuurd bericht:
>>
>> Van: Help-Desk <jira-help-desk at fi-ware.org <mailto:jira-help-desk at fi-ware.org>>
>> Onderwerp: [FIWARE-JIRA] (HELP-6964) [Fiware-tech-help] Securing verbs via the PEP proxy
>> Datum: 31 augustus 2016 10:24:00 CEST
>> Aan: c.meijer at itude.com <mailto:c.meijer at itude.com>, aalonsog at dit.upm.es <mailto:aalonsog at dit.upm.es>, k.patenaude at itude.com <mailto:k.patenaude at itude.com>, c.houtman at itude.com <mailto:c.houtman at itude.com>, e.bon at itude.com <mailto:e.bon at itude.com>
>> Kopie: s.vos at itude.com <mailto:s.vos at itude.com>, c.meijer at itude.com <mailto:c.meijer at itude.com>, aalonsog at dit.upm.es <mailto:aalonsog at dit.upm.es>, babbler at itude.com <mailto:babbler at itude.com>, k.patenaude at itude.com <mailto:k.patenaude at itude.com>, c.houtman at itude.com <mailto:c.houtman at itude.com>, e.bon at itude.com <mailto:e.bon at itude.com>
>> Antwoord aan: jira-help-desk at fi-ware.org <mailto:jira-help-desk at fi-ware.org>
>>
>>
>>
>
FW External User - Friday 4:19 PM
------------------
Comment by s.vos at itude.com :
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 ?
Kind Regards,
Simon Vos
Arthur van Schendelstraat 650
3511 MJ Utrecht
■ mob +31(0) 6 21 49 93 82
■ tel receptie +31(0)30 699 70 20
■ mail s.vos at itude.com <mailto:s.vos at itude.com>
■ linkedIn linkedin.com/in/simonvos <https://linkedin.com/in/simonvos>
www.itude.com <http://www.itude.com/> ■ K.v.K. 30146090
_____________________________________________________________________________
***Op deze mail is een disclaimer van toepassing. De inhoud daarvan is te lezen op onze website***
> Begin doorgestuurd bericht:
>
> Van: Help-Desk <jira-help-desk at fi-ware.org>
> Onderwerp: [FIWARE-JIRA] (HELP-6964) [Fiware-tech-help] Securing verbs via the PEP proxy
> Datum: 31 augustus 2016 10:24:00 CEST
> Aan: c.meijer at itude.com, aalonsog at dit.upm.es, k.patenaude at itude.com, c.houtman at itude.com, e.bon at itude.com
> Kopie: s.vos at itude.com, c.meijer at itude.com, aalonsog at dit.upm.es, babbler at itude.com, k.patenaude at itude.com, c.houtman at itude.com, e.bon at itude.com
> Antwoord aan: jira-help-desk at fi-ware.org
>
>
>
Alvaro Alonso - 12/Sep/16 12:26 PM
------------------
Closed for inactivity
Alvaro Alonso - 05/Sep/16 12:02 PM
------------------
Hi Cristian, I need to see the Horizon logs
FW External User - 05/Sep/16 11:21 AM
------------------
Comment by c.meijer at itude.com :
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?
2016-08-29 18:25 GMT+02:00 Help-Desk <jira-help-desk at fi-ware.org>:
> 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?
>
> {noformat}
> ACCESS_CONTROL_URL = 'http://idm.dev.babbler.io:8080'
> ACCESS_CONTROL_MAGIC_KEY = 'undefined'
> {noformat}
>
> Thanks.
>
>
>
> ------------------------------------------------------------
> -------------------
> Cyril Dangerville created HELP-6964:
> ---------------------------------------
>
> Summary: [Fiware-tech-help] Securing verbs via the PEP proxy
> Key: HELP-6964
> URL: https://jira.fiware.org/browse/HELP-6964
> Project: Help-Desk
> Issue Type: extRequest
> Components: FIWARE-TECH-HELP
> Reporter: FW External User
> Assignee: Cyril Dangerville
>
>
> Hello,
>
> We would like to secure out ContextBroker so POSTS are allowed, but a
> DELETE isn't. We've asked you about this and you've said we should do the
> following:
>
> * You can configure as many PEPs as you want. You have only to modify the
> > listening port.
> > * You can configure an AuthZForce in
> > https://github.com/ging/horizon/blob/master/openstack_
> dashboard/local/local_settings.py.example#L629.
> > You only need to configure the URL in which it is listening
> > * To configure PEP to work with AuthZForce you have to use the Level 2 of
> > security. Here you will find tutorials about this:
> > https://edu.fiware.org/course/view.php?id=131
>
>
> We've tried this, but we've had the following problems:
>
> - If we pull the docker image of
> fiware/authzforce-ce-server:release-5.4.0 or release-5.3.0a, the image
> starts, but shuts down after a few seconds after which the logs state
> that
> tomcat 7 can't be started.
> - When we run fiware/authzforce-ce-server:release-4.4.1b, we get a
> tomcat with no webapp in the webapps directory other than the default
> stuff.
> - Performing a manual installation using this guide
> <http://authzforce-ce-fiware.readthedocs.io/en/release-5.3.0a/
> InstallationAndAdministrationGuide.html#installation>
> will
> have the same result.
>
> In your previous mail, it is stated that we need AuthZForce. However,
> Keypass seems to do something similar. Can you explain the difference?
>
> Can you help us with this?
>
> --
>
> *Cristan Meijer*
> Software engineer
>
>
> Lageweg 2 3703 CA Zeist
> ■ *mob *+31(0) 6 45 372 363
> ■ *tel* +31(0)30 699 70 20
> ■ *mail* c.meijer at itude.com
>
> www.itude.com ■ K.v.K. 30146090
>
Cyril Dangerville - 31/Aug/16 10:23 AM
------------------
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.
Cyril Dangerville - 29/Aug/16 6:24 PM
------------------
The issue has been emailed: \\
- Time sent: *29/Aug/16 6:24 PM*
- To: *c.meijer at itude.com*
- Cc: *k.patenaude at itude.com,c.houtman at itude.com,e.bon at itude.com,aalonsog at dit.upm.es *
- with subject: *[Fiware-tech-help] Securing verbs via the PEP proxy*
\\
----
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?
{noformat}
ACCESS_CONTROL_URL = 'http://idm.dev.babbler.io:8080'
ACCESS_CONTROL_MAGIC_KEY = 'undefined'
{noformat}
Thanks.
Alvaro Alonso - 24/Aug/16 1:39 PM
------------------
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.
FW External User - 18/Aug/16 5:15 PM
------------------
Comment by c.meijer at itude.com :
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": [{"base": "application/json",
"type": "application/vnd.openstack.identity-v3+json"}, {"base":
"application/xml", "type": "application/vnd.openstack.identity-v3+xml"}],
"id": "v3.0", "links": [{"href": "http://127.0.0.1:35357/v3/", "rel":
"self"}]}}
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:
{SHA1}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": {"self": "
http://127.0.0.1:35357/v3/OS-ROLES/permissions/017f1597bca949069580b54a2a793acf"},
"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:
# 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.
Kind regards,
Cristan Meijer
2016-08-18 1:33 GMT+02:00 Help-Desk <jira-help-desk at fi-ware.org>:
>
>
Cyril Dangerville - 18/Aug/16 1:32 AM
------------------
The issue has been emailed: \\
- Time sent: *18/Aug/16 1:32 AM*
- To: *e.bon at itube.com,cyril.dangerville at thalesgroup.com*
- Cc: *s.vos at itude.com,c.meijer at itude.com,k.patenaude at itude.com,fefernandez at dit.upm.es,c.houtman at itude.com,aalonsog at dit.upm.es *
- with subject: *(HELP-6964) [Fiware-tech-help] Securing verbs via the PEP proxy *
\\
----
Hello,
unfortunately, I cannot reach the usual contacts in the Keyrock team (Alvaro and Frederico) at the moment (probably on leave). Till they get back, I suggest to enable DEBUG logs in Horizon. This is done by changing the _LOGGING_/_handlers_/_console_/_level_ value to _DEBUG_ in the configuration file [local_settings.py|http://fiware-idm.readthedocs.io/en/latest/developer_guide.html#local-settings]:
{code:javascript}
...
LOGGING = {
...
'handlers': {
...
'console': {
# Set the level to "DEBUG" for verbose output logging.
'level': 'DEBUG',
'class': 'logging.StreamHandler',
},
...
{code}
Then uncomment (remove _#_ character) all the lines with {noformat}
LOG.debug(...)
{noformat} in the file _openstack_dashboard/fiware_api/access_control_ge.py_ in order to enable all possible debug messages regarding Keyrock-Authzforce interactions.
Finally, restart Horizon, and check the logs in the console when you try to save rules/permissions in the dashboard again.
According to the code in _openstack_dashboard/fiware_api/access_control_ge.py_, you should see logs like this at least:
{noformat}
Access Control Domain not created, creating it...
...
Domain created: XXXX
...
{noformat}
You may send the logs to us for analysis if necessary. Thanks.
Regards,
Cyril
FW External User - 12/Aug/16 11:03 AM
------------------
Comment by e.bon at itude.com :
Dear sirs,
Is there any progress on this issue?
Met vriendelijke groeten,
Emiel Bon MSc
Software Engineer
Lageweg 2
3703 CA Zeist
■ mob +31(0) 6 29 20 95 40
■ mail e.bon at itude.com <mailto:e.prins at itude.com>
www.itude.com <http://www.itude.com/> ■ K.v.K. 30146090
_____________________________________________________________________________
***Op deze mail is een disclaimer van toepassing. De inhoud daarvan is te lezen op onze website***
> Op 5 aug. 2016, om 10:42 heeft Help-Desk <jira-help-desk at fi-ware.org> het volgende geschreven:
>
>
>
Cyril Dangerville - 05/Aug/16 10:41 AM
------------------
The issue has been emailed: \\
- Time sent: *05/Aug/16 10:41 AM*
- To: *fefernandez at dit.upm.es,aalonsog at dit.upm.es *
- Cc: *s.vos at itude.com,c.meijer at itude.com,e.bon at itube.com,k.patenaude at itude.com,c.houtman at itude.com,cyril.dangerville at thalesgroup.com,aalonsog at dit.upm.es *
- with subject: *(HELP-6964) [Fiware-tech-help] Securing verbs via the PEP proxy *
\\
----
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)
FW External User - 04/Aug/16 6:36 PM
------------------
Comment by e.bon at itude.com :
Dear sirs,
Thank you for your response. I have changed the url like so:
# 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.
Met vriendelijke groeten,
Emiel Bon MSc
Software Engineer
Lageweg 2
3703 CA Zeist
■ mob +31(0) 6 29 20 95 40
■ mail e.bon at itude.com <mailto:e.prins at itude.com>
www.itude.com <http://www.itude.com/> ■ K.v.K. 30146090
_____________________________________________________________________________
***Op deze mail is een disclaimer van toepassing. De inhoud daarvan is te lezen op onze website***
> Op 3 aug. 2016, om 15:05 heeft Help-Desk <jira-help-desk at fi-ware.org> het volgende geschreven:
>
>
>
Cyril Dangerville - 03/Aug/16 3:04 PM
------------------
The issue has been emailed: \\
- Time sent: *03/Aug/16 3:04 PM*
- To: *e.bon at itube.com,k.patenaude at itude.com*
- Cc: *s.vos at itude.com,c.meijer at itude.com,c.houtman at itude.com,cyril.dangerville at thalesgroup.com,aalonsog at dit.upm.es *
- with subject: *(HELP-6964) [Fiware-tech-help] Securing verbs via the PEP proxy *
\\
----
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
Alvaro Alonso - 03/Aug/16 11:53 AM
------------------
Yes, you have to use the root URL.
Cyril Dangerville - 02/Aug/16 12:55 PM
------------------
The issue has been emailed: \\
- Time sent: *02/Aug/16 12:55 PM*
- To: *e.bon at itube.com,k.patenaude at itude.com,aalonsog at dit.upm.es *
- Cc: *s.vos at itude.com,c.meijer at itude.com,c.houtman at itude.com*
- with subject: *(HELP-6964) [Fiware-tech-help] Securing verbs via the PEP proxy *
\\
----
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
FW External User - 29/Jul/16 3:48 PM
------------------
Comment by e.bon at itude.com :
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:
# 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?
Met vriendelijke groeten,
Emiel Bon MSc
Software Engineer
Lageweg 2
3703 CA Zeist
■ mob +31(0) 6 29 20 95 40
■ mail e.bon at itude.com <mailto:e.prins at itude.com>
www.itude.com <http://www.itude.com/> ■ K.v.K. 30146090
_____________________________________________________________________________
***Op deze mail is een disclaimer van toepassing. De inhoud daarvan is te lezen op onze website***
> Op 29 jul. 2016, om 09:17 heeft Help-Desk <jira-help-desk at fi-ware.org> het volgende geschreven:
>
>
>
Alvaro Alonso - 29/Jul/16 9:16 AM
------------------
Hi, I also recommend to install latest releases of both components.
Cyril Dangerville - 28/Jul/16 3:04 PM
------------------
The issue has been emailed: \\
- Time sent: *28/Jul/16 3:04 PM*
- To: *k.patenaude at itude.com,aalonsog at dit.upm.es *
- Cc: *s.vos at itude.com,c.meijer at itude.com,c.houtman at itude.com,e.bon at itude.com*
- with subject: *[Fiware-tech-help] Securing verbs via the PEP proxy*
\\
----
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?
FW External User - 28/Jul/16 9:56 AM
------------------
Comment by k.patenaude at itude.com :
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,
*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
On Wed, Jul 27, 2016 at 6:16 PM, Cristan Meijer <c.meijer at itude.com> wrote:
> Het lijkt me slim om dit te beantwoorden en hierin te vermelden de
> foutmelding die jullie nu krijgen.
>
> ---------- Forwarded message ----------
>
Cyril Dangerville - 27/Jul/16 12:25 PM
------------------
The issue has been emailed: \\
- Time sent: *27/Jul/16 12:25 PM*
- To: *c.meijer at itude.com*
- Cc: *aalonsog at dit.upm.es,babbler at itude.com,c.houtman at itude.com*
- with subject: *[Fiware-tech-help] Securing verbs via the PEP proxy*
\\
----
Dear Mr Meijer,
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
FW External User - 27/Jul/16 9:16 AM
------------------
Comment by aalonsog at 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.
BR
--
Álvaro
> El 25 jul 2016, a las 16:57, Coen Houtman <c.houtman at itude.com> escribió:
>
> 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.
>
> Kind regards,
>
> On Fri, Jul 22, 2016 at 10:35 AM Cristan Meijer <c.meijer at itude.com <mailto:c.meijer at itude.com>> wrote:
> Hello,
>
> We would like to secure out ContextBroker so POSTS are allowed, but a DELETE isn't. We've asked you about this and you've said we should do the following:
>
> * You can configure as many PEPs as you want. You have only to modify the listening port.
> * You can configure an AuthZForce in https://github.com/ging/horizon/blob/master/openstack_dashboard/local/local_settings.py.example#L629 <https://github.com/ging/horizon/blob/master/openstack_dashboard/local/local_settings.py.example#L629>. You only need to configure the URL in which it is listening
> * To configure PEP to work with AuthZForce you have to use the Level 2 of security. Here you will find tutorials about this: https://edu.fiware.org/course/view.php?id=131 <https://edu.fiware.org/course/view.php?id=131>
> We've tried this, but we've had the following problems:
> If we pull the docker image of fiware/authzforce-ce-server:release-5.4.0 or release-5.3.0a, the image starts, but shuts down after a few seconds after which the logs state that tomcat 7 can't be started.
> When we run fiware/authzforce-ce-server:release-4.4.1b, we get a tomcat with no webapp in the webapps directory other than the default stuff.
> Performing a manual installation using this guide <http://authzforce-ce-fiware.readthedocs.io/en/release-5.3.0a/InstallationAndAdministrationGuide.html#installation> will have the same result.
> In your previous mail, it is stated that we need AuthZForce. However, Keypass seems to do something similar. Can you explain the difference?
>
> Can you help us with this?
>
> --
> Cristan Meijer
> Software engineer
>
> <PastedGraphic-2.png>
> Lageweg 2 3703 CA Zeist
> ■ mob +31(0) 6 45 372 363
> ■ tel +31(0)30 699 70 20
> ■ mail c.meijer at itude.com <mailto:c.meijer at itude.com>
>
> www.itude.com <http://www.itude.com/> ■ K.v.K. 30146090
>
Alvaro Alonso - 27/Jul/16 8:52 AM
------------------
I assign this ticket to the AuthZForce owner.
BR
FW External User - 25/Jul/16 5:01 PM
------------------
Comment by c.houtman at itude.com :
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.
Kind regards,
On Fri, Jul 22, 2016 at 10:35 AM Cristan Meijer <c.meijer at itude.com> wrote:
> Hello,
>
> We would like to secure out ContextBroker so POSTS are allowed, but a
> DELETE isn't. We've asked you about this and you've said we should do the
> following:
>
> * You can configure as many PEPs as you want. You have only to modify the
>> listening port.
>> * You can configure an AuthZForce in
>> https://github.com/ging/horizon/blob/master/openstack_dashboard/local/local_settings.py.example#L629.
>> You only need to configure the URL in which it is listening
>> * To configure PEP to work with AuthZForce you have to use the Level 2 of
>> security. Here you will find tutorials about this:
>> https://edu.fiware.org/course/view.php?id=131
>
>
> We've tried this, but we've had the following problems:
>
> - If we pull the docker image of
> fiware/authzforce-ce-server:release-5.4.0 or release-5.3.0a, the image
> starts, but shuts down after a few seconds after which the logs state that
> tomcat 7 can't be started.
> - When we run fiware/authzforce-ce-server:release-4.4.1b, we get a
> tomcat with no webapp in the webapps directory other than the default
> stuff.
> - Performing a manual installation using this guide
> <http://authzforce-ce-fiware.readthedocs.io/en/release-5.3.0a/InstallationAndAdministrationGuide.html#installation> will
> have the same result.
>
> In your previous mail, it is stated that we need AuthZForce. However,
> Keypass seems to do something similar. Can you explain the difference?
>
> Can you help us with this?
>
> --
>
> *Cristan Meijer*
> Software engineer
>
> [image: PastedGraphic-2.png]
> Lageweg 2 3703 CA Zeist
> ■ *mob *+31(0) 6 45 372 363
> ■ *tel* +31(0)30 699 70 20
> ■ *mail* c.meijer at itude.com
>
> www.itude.com ■ K.v.K. 30146090
>
>
------------------------
Issue id: HELP-6964
Description:
Hello,
We would like to secure out ContextBroker so POSTS are allowed, but a
DELETE isn't. We've asked you about this and you've said we should do the
following:
* You can configure as many PEPs as you want. You have only to modify the
> listening port.
> * You can configure an AuthZForce in
> https://github.com/ging/horizon/blob/master/openstack_dashboard/local/local_settings.py.example#L629.
> You only need to configure the URL in which it is listening
> * To configure PEP to work with AuthZForce you have to use the Level 2 of
> security. Here you will find tutorials about this:
> https://edu.fiware.org/course/view.php?id=131
We've tried this, but we've had the following problems:
- If we pull the docker image of
fiware/authzforce-ce-server:release-5.4.0 or release-5.3.0a, the image
starts, but shuts down after a few seconds after which the logs state that
tomcat 7 can't be started.
- When we run fiware/authzforce-ce-server:release-4.4.1b, we get a
tomcat with no webapp in the webapps directory other than the default
stuff.
- Performing a manual installation using this guide
<http://authzforce-ce-fiware.readthedocs.io/en/release-5.3.0a/InstallationAndAdministrationGuide.html#installation>
will
have the same result.
In your previous mail, it is stated that we need AuthZForce. However,
Keypass seems to do something similar. Can you explain the difference?
Can you help us with this?
--
*Cristan Meijer*
Software engineer
Lageweg 2 3703 CA Zeist
■ *mob *+31(0) 6 45 372 363
■ *tel* +31(0)30 699 70 20
■ *mail* c.meijer at itude.com
www.itude.com ■ K.v.K. 30146090
_____________________________________________________________________________
****Op deze mail is een disclaimer van toepassing. De inhoud daarvan is te
lezen op onze website****
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: Cristan Meijer <c.meijer at itude.com>]
FIWARE Chapter:
FIWARE GEri:
Status: Closed
Resolution: Done
---------------------
This email was generated by FIWARE JIRA following an email received into the Main Help Desk.
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy