Setting up a PEP proxy
I am working on PEP-Proxy-Steelskin so I can provide some level of security to my Orion content, however there are some issues blocking my progress.
I like to use IDM and Keystone Global Instances.
I have successfully installed pepProxy following the appropriate directions ( https://github.com/telefonicaid/fiware-pep-steelskin ), however the result is always the same:
{
"name": "KEYSTONE_AUTHENTICATION_ERROR",
"message": "There was a connection error while authenticating to Keystone: 500"
}
My configuration used in the file config.js
is below:
var config = {};
// Protected Resource configuration
//--------------------------------------------------
// Configures the address of the component that is being proxied and the address of the proxy itself.
config.resource = {
original: {
/**
* Host that is being proxied.
*/
host: 'account.lab.fiware.org',
/**
* Port where the proxied server is listening.
*/
port: 10026
},
proxy: {
/**
* Port where the proxy is listening to redirect requests.
*/
port: 1026,
/**
* Administration port for the proxy.
*/
adminPort: 11211
}
};
// Access Control configuration
//--------------------------------------------------
/**
* This options can be used to configure the address and options of the Access Control, responsible of the request
* validation.
*/
config.access = {
/**
* Indicates whether the access control validation should be enabled. Defaults to false.
*/
disable: false,
/**
* Protocol to use to access the Access Control.
*/
protocol: 'http',
/**
* Host where the Access Control is located.
*/
host: 'account.lab.fiware.org',
/**
* Port where the Access Control is listening.
*/
port: 7070,
/**
* Path of the authentication action.
*/
path: '/pdp/v3'
}
// User identity configuration
//--------------------------------------------------
/**
* Information about the Identity Manager server from where the information about a user will be drawn.
*/
config.authentication = {
checkHeaders: false,
module: 'keystone',
user: 'pep_proxy_99c595...',
password: 'e3025a2...',
domainName: 'matest',
retries: 3,
cacheTTLs: {
users: 1000,
projectIds: 1000,
roles: 60,
validation: 120
},
options: {
protocol: 'http',
host: 'cloud.lab.fiware.org',
port: 5000,
path: '/v3/role_assignments',
authPath: '/v3/auth/tokens'
}
};
// Security configuration
//--------------------------------------------------
config.ssl = {
/**
* This flag activates the HTTPS protocol in the server. The endpoint always listen to the indicated port
* independently of the chosen protocol.
*/
active: false,
/**
* Key file to use for codifying the HTTPS requests. Only mandatory when the flag active is true.
*/
keyFile: '',
/**
* SSL Certificate to present to the clients. Only mandatory when the flag active is true.
*/
certFile: ''
}
/**
* Default log level. Can be one of: 'DEBUG', 'INFO', 'WARN', 'ERROR', 'FATAL'
*/
config.logLevel = 'FATAL';
// List of component middlewares
//-------------------------------------------------
/**
* To validate the request, the proxy needs some information that is dependant of the component: the action that a
* request is going to execute. How to detect the action given the request is component-specific logic, that can be
* codified in a middleware-like function that will be executed before the user validation. This logic must populate
* the 'action' parameter of the request.
*/
config.middlewares = {
/**
* Indicates the module from where the middlewares will be loaded.
*/
require: 'lib/plugins/orionPlugin',
/**
* Indicates the list of middlewares to load.
*/
functions: [
'extractCBAction'
]
};
/**
* If this flag is activated, whenever the pepProxy is not able to redirect a request, instead of returning a 501 error
* (that is the default functionality) the PEP Proxy process will exit with a -2 code.
*/
config.dieOnRedirectError = false;
/**
* Name of the component. It will be used in the generation of the FRN.
*/
config.componentName = 'orion';
/**
* Prefix to use in the FRN (Not to change, usually).
*/
config.resourceNamePrefix = 'fiware:';
/**
* Indicates whether this PEP should have an admin bypass or not. If it does, whenever a user request arrives to the
* PEP from a user that has the role defined in the "adminRoleId" property, that request is not validated against the
* Access Control, but it is automatically proxied instead.
*/
config.bypass = false;
/**
* ID of the admin user if it exists. Only effective if the "bypass" property is true.
*/
config.bypassRoleId = '';
/**
* Configures the maximum number of clients that can be simultaneously queued while waiting for the PEP to
* authenticate itself against Keystone (due to an expired token).
*/
config.maxQueuedClients = 1000;
module.exports = config;
In this context:
- Is it correct to use
account.lab.fiware.org
both resource and access host, or use another? - Can I be used
cloud.lab.fiware.org
as an authentication host? - The user and password are automatically generated by my IDM Global domain. Roles and privileges are assigned through the same Global Instance. Is this procedure consistent or should I follow a different one?
- Did I miss something?
Does anyone have a hint of my problems?
Notes: I have already tried different posts with success. Partly because many of these decisions have established their own keystone, for example configuration of the magazine-the Proxy-PEP Steelskin , configuration file proxy PEP to integrate IDM GE, PEP proxy and large Cosmos data , log-proxy-configuration PEP Steelskin . This is the one that has more to do with what I was working on, but nonetheless, I believe it is not relevant: Fiware Orion - pepProxy
source to share
I @ netzahdzc sorry if this is not the answer you are hoping for, but I have not been working with Fiware technologies for a while and so I do not remember everything, but I will try to help.
Is it correct to use account.lab.fiware.org as resource and access host, or should I use a different one?
I think you are using the correct one, please refer to the config files of my project on GitHub , this project is "old" and therefore some things may have already changed on the Fiware side ... as you can see in the PepProxy - config. js, the instance I used was the same as you:
config.account_host = 'https://account.lab.fiware.org';
config.keystone_host = 'cloud.lab.fiware.org';
config.keystone_port = 4730;
Is it correct to use cloud.lab.fiware.org as an authentication host?
In the config I used (above), you can see that account_host is account.lab.fiware.org and keystone_host (for authentication) is cloud.lab.fiware.org , so I think you are correct.
The user and password are automatically generated by my IDM Global domain. Roles and privileges are assigned through the same Global Instance. Is this procedure consistent or should I follow a different one?
I don't dive into this very much, but to remind you that you are correct, roles and permissions should be handled by Keystone Global Instance, but I don't know if changes have changed since I worked with this.
Sorry if I can't help more, please try to find out if you can use some of my settings or at least it might help you. You can also try to talk to Daniel Moran Jimenez , I think he could help you better than me.
source to share
Did you succeed with what you suggest?
I think that if you want to use the global IdM instance as an identity provider for authentication, you need to fill in the config.js values as shown in the following snippet, but I'm not sure if this will work.
// User identity configuration
//--------------------------------------------------
/**
* Information about the Identity Manager server from where the information about a user will be drawn.
*/
config.authentication = {
checkHeaders: true,
module: 'keystone',
user: 'pep_proxy_1234...',
password: 'my-autogenerated-password',
domainName: 'Default',
retries: 3,
cacheTTLs: {
users: 1000,
projectIds: 1000,
roles: 60,
validation: 120
},
options: {
protocol: 'http',
host: 'cloud.lab.fiware.org',
port: 4730,
path: '/v3/role_assignments',
authPath: '/v3/auth/tokens'
}
};
Of course, replace the user and password fields with the values automatically generated by your global IDM instance.
However, I think you should use the GEEP ( Wilma PEP Proxy ) reference proxy implementation if you still want to use a global Fiware Cloud instance.
You are using the Telefonica implementation of this GE , which in my opinion has some differences from Wilma and I am not 100% sure if it can be integrated with the reference implementations of IdM Keyrock and Authzforce PDP Authorization that use the global Fiware Cloud instance .
A completely different approach, perhaps using your own instances of IdM, PDP Authorization and PEP Proxy Generic Enablers (GE). In this case, you can still use the link implementation of these three components, or use the Steelskin PEP proxy. If you are following the Steelskin path, I recommend that you use Keystone-spassword and Keypass , which are Telefonica IdM implementations and authorization PDPs respectively. Here you can find an excellent step by step on how to install and configure these GEs.
Finally, if you want to follow GE's "referencing path," you can find some light in these slides .
Hello,
Emiliano
source to share