[ https://jira.fiware.org/browse/HELP-6964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=54412#comment-54412 ]
Fernando Lopez edited comment on HELP-6964 at 9/24/19 8:44 AM:
---------------------------------------------------------------
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.
was (Author: fw.external.urser):
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>:
>
>
> 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