Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problem to compare AZF response and string 'Permit' #36

Open
gabicavalcante opened this issue Dec 16, 2016 · 5 comments
Open

Problem to compare AZF response and string 'Permit' #36

gabicavalcante opened this issue Dec 16, 2016 · 5 comments

Comments

@gabicavalcante
Copy link
Contributor

gabicavalcante commented Dec 16, 2016

I’m trying make the Level 2 authorization using PEP, IdM and AZF.

I have created a REST web service that exposes one GET service 'service2/list'. I have created a permission to make a GET to the resource service2/list and a role 'developer', and associated the permission to the role ‘developer’. I created a user too, and I assigned 'developer' and ‘provider’ roles to my user.

I have changed the file /horizon/openstack_dashboard/local/local_settings.py to connect the keyrock with authzforce:

    ACCESS_CONTROL_URL = 'http://192.168.99.100:8080'
    ACCESS_CONTROL_MAGIC_KEY = 'undefined'

And my PEP configuration:

    config.azf = {
            enabled: true,
            protocol: 'http',
            host: '192.168.99.100',
            port: 8080,
            custom_policy: undefined // use undefined to default policy checks (HTTP verb + path).
    };

The call to the resource is intercepted by PEP, and initially it show me a error:

    pep-proxy_1  | 2016-12-14 16:49:44.474  - INFO: IDM-Client - Checking token with IDM… 
    pep-proxy_1  | 2016-12-14 16:49:44.531  - INFO: AZF-Client - Checking auth with AZF...
    pep-proxy_1  | 2016-12-14 16:49:44.533  - INFO: AZF-Client - Checking authorization to roles [ 'c6653c957bc34b96be0e197b56bb17c1', 'provider' ] to do  GET  on  service2/list and app  9c3cb030636144abaca85ccfdd64c173
    pep-proxy_1  | 2016-12-14 16:49:44.534  - INFO: AZF-Client - Checking auth with AZF…  
    pep-proxy_1  | 2016-12-14 16:49:45.366  - ERROR: Root - User access-token not authorized:  User not authorized in AZF for the given action and resource

So I activated the debug from authzforce and I checked that everything was working. Then I look into pep files, and I found the file lib/azf.js:

    log.debug('Decision: ', decision);
    if (decision === 'Permit') {
            success();
    } else {
            error(401, 'User not authorized in AZF for the given action and resource');
    }

I activated the debug from pep too, and I got it:

    pep-proxy_1  | 2016-12-16 21:16:31.684  - DEBUG: AZF-Client - AZF response status:  200
    pep-proxy_1  | 2016-12-16 21:16:31.684  - DEBUG: AZF-Client - AZF response:  <?xml version="1.0" encoding="UTF-8" standalone="yes"?><Response xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17" xmlns:ns2="http://authzforce.github.io/core/xmlns/pdp/5.0" xmlns:ns3="http://authzforce.github.io/rest-api-model/xmlns/authz/5" xmlns:ns4="http://authzforce.github.io/pap-dao-flat-file/xmlns/properties/3.6" xmlns:ns5="http://www.w3.org/2005/Atom"><Result><Decision>Permit</Decision></Result></Response>
    pep-proxy_1  | 2016-12-16 21:16:31.697  - DEBUG: AZF-Client - AZF response parsing result (JSON):  { Response: 
    pep-proxy_1  |    { '$': 
    pep-proxy_1  |       { xmlns: 'urn:oasis:names:tc:xacml:3.0:core:schema:wd-17',
    pep-proxy_1  |         'xmlns:ns2': 'http://authzforce.github.io/core/xmlns/pdp/5.0',
    pep-proxy_1  |         'xmlns:ns3': 'http://authzforce.github.io/rest-api-model/xmlns/authz/5',
    pep-proxy_1  |         'xmlns:ns4': 'http://authzforce.github.io/pap-dao-flat-file/xmlns/properties/3.6',
    pep-proxy_1  |         'xmlns:ns5': 'http://www.w3.org/2005/Atom' },
    pep-proxy_1  |      Result: [ [Object] ] } }
    pep-proxy_1  | 2016-12-16 21:16:31.698  - DEBUG: AZF-Client - AZF response parsing error ('null' means no error):  null
    pep-proxy_1  | 2016-12-16 21:16:31.699  - DEBUG: AZF-Client - Decision:  [ 'Permit' ]
    pep-proxy_1  | 2016-12-16 21:16:31.699  - ERROR: Root - User access-token not authorized:  User not authorized in AZF for the given action and resource

As you can see, we received ‘Permit’ as response. After a checked the type of decision, and I saw ‘object’. And for javascript when === is used, object type is different of string type. So I changed the === to == and worked. Another solution is make a parser before compare, to convert the object variable to string.

@aalonsog
Copy link
Member

aalonsog commented Feb 9, 2017

Thanks! Could you fix this in a PR?

gabicavalcante added a commit to gabicavalcante/fiware-pep-proxy that referenced this issue Feb 15, 2017
aalonsog pushed a commit that referenced this issue Feb 15, 2017
@carlospg79
Copy link

Hi @aalonsog, I'm testing pep-proxy with my own authzforce server and this problem has returned after the commit 939ff16
The main problem is that decision[0]==='Permit' compares 'P' with 'Permit'.
The previous code works, so i ask why you added this change? the SEC-1044 is unknown for me.

@joansrios
Copy link

@aalonsog and @carlospg79, The error still persists for me, then i asked this, do you find a solution?

https://stackoverflow.com/questions/49684767/fiware-configure-authzforce-with-pep-proxy

@carlospg79
Copy link

carlospg79 commented Apr 9, 2018

i checked your stackoverflow questions. What solved my problem is that in keyrock you need to not use admin user. For admin user, all the request are forbidden. also, the authzforce 6.0.0 didn't work also (at least for me) so i used the previous 5.4.0 version. i don't know if it can help you.

Last week, new keyrock version has been released, so maybe the best is change to that version.

@joansrios
Copy link

@carlospg79 what do you mean with the forbiden requests for the admin user. I'm using the authzforce 5.4.1. And didnt work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants