[ https://jira.fiware.org/browse/HELP-6964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=54839#comment-54839 ]
Fernando Lopez edited comment on HELP-6964 at 9/24/19 8:45 AM:
---------------------------------------------------------------
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?
was (Author: fw.external.urser):
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
>
> FIWARE.Request.Tech.Security.AuthorizationPDP.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: Alvaro Alonso
> Attachments: 2016-09-05 08_57_48.486 21 INFO eventlet.wsgi.txt, Logs IDM_Horizon after creating permission_HTTP.txt rule in IDM, ParseError at _idm_myApplications_fdae7d987c6a435188a2200e31cac4db_edit_roles_.html
>
>
> 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?
--
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