Problem in interaction between idm,pep and authzforce #7
Comments
|
Hello, as far as I understand, if the "HTTP/1.1 400 Bad Request" in your capture is the response from AZF, then the request that is causing it should be visible just before. Unfortunately, I cannot find it here. Is it anywhere in your packet capture so I can see what's wrong with it that is causing the error 400 response from AZF? |
|
Hi @cdanger! I'll provide you with the capture result on Monday. To me it's just some binary content sent to the authzforce port, so I doubt that would be helpful. It's definitely no valid request so I totally agree with AZF's response but also don't know what triggers this response. Anyway, we will see soon. |
|
Hello, I found the time to setup a IdM-PEP-AZF infrastructure with latest Docker releases at last, and indeed, I faced a couple of issues in the PEP proxy and one in the IdM. I do not own these components, so I did what I could to fix things quickly. For long-term fixes, I reported specific issues on their respective github repositories and created pull requests, so we'll have to wait for the next releases. In the meantime, I can tell you the quick fixes I did. First, I assume you still have an AZF Docker container up and running, probably the version 5.4.0b which was the latest at the time you created the issue. You may upgrade to 5.4.1 which I released more recently. Anyway, this is just for your info, and will not fix the issue here. As for the IdM, especially the dashboard, you have to fix issues:
Then restart the IdM container after fixing the files. As for the PEP, you have to fix issues:
docker run -d --name pep-proxy -v /home/toto/fiware-pep-proxy/config.js:/opt/fiware-pep-proxy/config.js -v /home/toto/fiware-pep-proxy/log_config.json:/opt/fiware-pep-proxy/log_config.json -p 80:80 fiware/pep-proxy:5.3.1My var config = {};
config.pep_port = 80;
// Set this var to undefined if you don't want the server to listen on HTTPS
config.https = {
enabled: false,
cert_file: 'cert/cert.crt',
key_file: 'cert/key.key',
port: 443
};
config.account_host = 'http://idm:8000';
config.keystone_host = 'idm';
config.keystone_port = 5000;
config.app_host = 'www.google.es';
config.app_port = '80';
// Use true if the app server listens in https
config.app_ssl = false;
// Credentials obtained when registering PEP Proxy in Account Portal
// Of course these are not the real ones I am using but just for example
config.username = 'pep_proxy_XXXXXXXX';
config.password = 'XXXXXXXXXXXXXX';
// in seconds
config.chache_time = 300;
// if enabled PEP checks permissions with AuthZForce GE.
// only compatible with oauth2 tokens engine
//
// you can use custom policy checks by including programatic scripts
// in policies folder. An script template is included there
config.azf = {
enabled: true,
protocol: 'http',
host: 'azf',
port: 8080,
custom_policy: undefined // use undefined to default policy checks (HTTP verb + path).
};
// list of paths that will not check authentication/authorization
// example: ['/public/*', '/static/css/']
config.public_paths = [];
// options: oauth2/keystone
config.tokens_engine = 'oauth2';
config.magic_key = undefined;
module.exports = config;Here I am using hostnames for the IdM and AZF hosts but you can use IP addresses of course. What is important is My {
"appenders": [
{
"type": "console",
"layout": {
"type": "pattern",
"pattern": "%d - %p: %c - %m",
"replaceConsole": true
}
}
],
"levels": {
"Server": "DEBUG",
"Root": "DEBUG",
"HTTP-Client": "DEBUG",
"AZF-Client": "DEBUG",
"IDM-Client": "DEBUG",
"Test": "DEBUG"
}
}
$ docker cp /home/toto/fiware-pep-proxy/lib/azf.js pep-proxy:/opt/fiware-pep-proxy/lib/azf.js
$ docker exec -t -i pep-proxyIn the container's shell, install the Node.js package $ npm install xml2jsExit the shell/container, restart the container and check that it starts OK with |
|
Thanks a lot @cdanger! I'm currently on vacations and will give your fixes a try once I'm back in office (about two weeks from now) and get some time for it. |
|
Now the fixes are parts of the new releases so you should upgrade to KeyRock v5.4.0, PEP Proxy v5.4 or later, AZF v5.4.1 or later. |
|
I am now closing this issue since no news from the OP for quite some time. You can re-open when you happen to reproduce the issue with new software versions. |
There's apparently a problem in the interaction between idm, authzforce and probably pep.
Since I cannot tell which component is the actual trouble maker, I've filed an issue at the IdM project as well. So please see this issue for a detailed description. I cannot see any rules in the PAP that correspond to the roles I have defined in IdM, although the IdM creates a valid domain.
As mentioned in the other issue, authentication between my client app and the IdM works perfectly fine. But whenever PEP tries to perform the authorization, things go terribly wrong.
Here's again the log from PEP:
Wireshark revealed the following:
PEP first checks the token with the IdM
Then the Idm provides the necessary information about the AFZ domain:
After this I cannot make out a valid http request sent from PEP to AFZ, nevertheless the following response pops up:
So maybe there's something wrong with the request sent from PEP. Nevertheless, could you please check whether the XML stored in AFZ looks ok (ging/fiware-idm#70)?
The permissions for role "Restaurant-Viewer" should be "GET" , "/v2/entities".
The text was updated successfully, but these errors were encountered: