问题
I've been working on regards the PEP-Proxy-Steelskin so I can provide some security layer to my Orion Context, however, there are some issues that have been blocking my progress.
I will like to use the IDM and Keystone Global Instances.
I've successfully install the pepProxy by following respective 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 at the config.js file is presented 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 right to use
account.lab.fiware.org, as resource and access host or should I use a different one? - Is it right to use
cloud.lab.fiware.org, as authentication host? - The user and password are automatically created by my IDM Global Instance. Roles and privileges are being assigned through the same Global Instance. Is this procedure appropriated or should I follow a different one?
- Am I missing something?
Does anyone have any hint to my issues?
Notes: I have already tried different post with success. In part because many of those solutions have installed their own keystone, for instance: PEP-Proxy-Steelskin Log configuration , PEP proxy config file for integration of IDM GE, PEP proxy and Cosmos big data , PEP-Proxy-Steelskin Log configuration. This one is the one that is more related to what I've been working on, but still, I believe is not up to date: Fiware Orion - pepProxy
回答1:
I @netzahdzc sorry if this is not the reply you hope, but I don't work with Fiware technologies for a while now, and so I don't recall everything but I will try to help.
Is it right to use account.lab.fiware.org, as resource and access host or should I use a different one?
I think you are using the right one, please refer to the configuration files of my project at GitHub, this project is "old" and so some things may have already been change from 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 right to use cloud.lab.fiware.org, as authentication host?
In the configuration I used (above) you can see that the account_host is the account.lab.fiware.org and the keystone_host (for authentication) is the cloud.lab.fiware.org, so I think you are right.
The user and password are automatically created by my IDM Global Instance. Roles and privileges are being assigned through the same Global Instance. Is this procedure appropriated or should I follow a different one?
I din't dive much into this but for what a recall yes you are right, the roles and permissions should be handle by the Keystone Global Instance but I don't know if things have change since I worked with this.
Sorry if I couldn't help more, try to see if you can use some of my configuration or if at least it can help you. You could also try to talk to Daniel Morán Jiménez, I believe he could help you better thant me.
回答2:
Have you been successful with what you propose?
I think that if you want to use the global instance of IdM, as an identity provider for authentication, you have to populate the config.js values as shown in the following snippet but I'm not sure if it's going to 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 fields user and password with the values automatically created by your IDM Global Instance.
However, I think you should use the reference implementation of the PEP proxy GE (Wilma PEP Proxy), in case you still want to use the global instance of Fiware Cloud.
You are using Telefonica implementation of this GE which from my point of view has some differences with Wilma and I am not 100% sure if it can be integrated with the reference implementations of the IdM Keyrock and the Authorization PDP Authzforce which use the global instance of Fiware Cloud.
A completely different approach, it may be to use your own instances of the IdM, PDP Authorization and PEP Proxy Generic Enablers (GEs). In that case you still could use the references implementation of this three components or you could use the Steelskin PEP Proxy. If you follow the Steelskin path I encourage you to use Keystone-spassword and Keypass which are the Telefonica's implementations of the IdM and the Authorization PDP respectively. Here you can found an excellent step by step about installing and configuring this GEs.
Finally if you want to follow the "references" GE path, you could find some light in this slides.
Regards,
Emiliano
来源：https://stackoverflow.com/questions/43808743/setting-up-pep-proxy