简体   繁体   English

设置PEP代理

[英]Setting up PEP Proxy

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. 我一直在研究PEP-Proxy-Steelskin,所以我可以为我的Orion Context提供一些安全层,但是,有些问题阻碍了我的进步。

I will like to use the IDM and Keystone Global Instances. 我想使用IDM和Keystone全局实例。

I've successfully install the pepProxy by following respective directions ( https://github.com/telefonicaid/fiware-pep-steelskin ), however, the result is always the same: 我按照各自的指示( https://github.com/telefonicaid/fiware-pep-steelskin )成功安装了pepProxy,但结果总是一样的:

{
"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: 我在config.js文件中使用的配置如下所示:

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: 在这方面:

  1. Is it right to use account.lab.fiware.org , as resource and access host or should I use a different one? 使用account.lab.fiware.org作为资源和访问主机是否正确,还是应该使用不同的主机?
  2. Is it right to use cloud.lab.fiware.org , as authentication host? 使用cloud.lab.fiware.org作为身份验证主机是否正确?
  3. The user and password are automatically created by my IDM Global Instance. 用户和密码由我的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? 这个程序是否被挪用或者我应该遵循另一个程序?
  4. 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 . 部分是因为其中许多解决方案都安装了自己的keystone,例如: PEP-Proxy-Steelskin日志配置PEP代理配置文件,用于集成IDM GE,PEP代理和Cosmos大数据PEP-Proxy-Steelskin日志配置 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 这个与我一直在做的事情更相关,但我相信还不是最新的: Fiware Orion - pepProxy

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. 我@netzahdzc对不起,如果这不是您希望的回复,但我暂时不使用Fiware技术,所以我不记得一切,但我会尽力帮助。

Is it right to use account.lab.fiware.org, as resource and access host or should I use a different one? 使用account.lab.fiware.org作为资源和访问主机是否正确,还是应该使用不同的主机?

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: 我认为你使用的是正确的,请参考GitHub项目的配置文件,这个项目是“旧”的,所以有些东西可能已经从Fiware方面改变了......正如你在PepProxy中看到的那样 - config.js我使用的实例和你一样:

    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? 使用cloud.lab.fiware.org作为身份验证主机是否正确?

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. 在我使用的配置(上图)中,您可以看到account_hostaccount.lab.fiware.orgkeystone_host (用于身份验证)是cloud.lab.fiware.org ,所以我认为你是对的。

The user and password are automatically created by my IDM Global Instance. 用户和密码由我的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. 我不会深入研究这个问题但是对于回忆是的你是对的,角色和权限应该由Keystone Global Instance处理,但我不知道自从我使用它以来是否有变化。

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. 您也可以尝试与DanielMoránJiménez交谈,我相信他可以帮助您更好地照顾我。

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. 我认为如果你想使用IdM的全局实例,作为身份验证的身份提供者,你必须填充config.js值,如下面的代码片段所示,但我不确定它是否会起作用。

// 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. 当然,将字段userpassword替换为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. 但是,我认为您应该使用PEP代理GE( Wilma PEP代理 )的参考实现,以防您仍然想要使用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 . 您正在使用Telefonica实施此GE ,从我的观点来看,它与Wilma存在一些差异,我不能100%确定它是否可以与IdM Keyrock授权PDP Authzforce的参考实现集成,后者使用全局实例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). 一种完全不同的方法,可能是使用您自己的IdM实例,PDP授权和PEP代理通用启动器(GE)。 In that case you still could use the references implementation of this three components or you could use the Steelskin PEP Proxy. 在这种情况下,您仍然可以使用这三个组件的引用实现,或者您可以使用Steelskin PEP代理。 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. 如果您遵循Steelskin路径,我建议您使用Keystone-spasswordKeypass ,它们分别是Telefonica的IdM和授权PDP实现。 Here you can found an excellent step by step about installing and configuring this GEs. 在这里,您可以找到有关安装和配置此GE的一步一步的优秀信息。

Finally if you want to follow the "references" GE path, you could find some light in this slides . 最后,如果您想要遵循“参考”GE路径,您可以在此幻灯片中找到一些亮点。

Regards, 问候,

Emiliano 埃米利亚诺

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM