[Backlogmanager] [FIWARE-JIRA] (HELP-8757) [fiware-stackoverflow] FIWare KeyRock: How to prevent fiware labs data being created when a new user registers

Fernando Lopez (JIRA) jira-help-desk at jira.fiware.org
Thu May 25 10:07:00 CEST 2017


     [ https://jira.fiware.org/browse/HELP-8757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Fernando Lopez updated HELP-8757:
---------------------------------
     HD-Chapter: Security
    Description: 
Created question in FIWARE Q/A platform on 30-04-2016 at 19:04
{color: red}Please, ANSWER this question AT{color} https://stackoverflow.com/questions/36958289/fiware-keyrock-how-to-prevent-fiware-labs-data-being-created-when-a-new-user-re


+Question:+
FIWare KeyRock: How to prevent fiware labs data being created when a new user registers

+Description:+
We want to use the FIWARE IdM, both Keystone and Horizon. Specifically during sign-up we want to


create a user
add that user to an organisation 
authorise the user for an application


We have installed Keystone and Horizon using the latest KeyRock docker image on the docker hub.
When a new user signs up:


a 'cloud organisation' is created. 
By default, the 'provider' and 'purchaser' roles are present 
and the 'Store' application is assigned to the user (although i cannot verify this).
We can add the user to an organisation by hand, and authorise the user for an application by hand in the KeyRock UI.


However this does not make any sense for our local installation.


How can we prevent Horizon from creating the cloud organisation upon user sign-up?
How can we assign a default application authorization upon user sign-up?


-- Edit --

It’s becoming increasingly clear to me that the way KeyRock is implemented is primarily useful for setting up your own Fiware labs environment, as opposed to setting up a generic Identity management service. If we use KeyRock, we will be stuck with cloud organisations, stores etc. Far from being a Generic Enabler (GE), KeyRock seems to be a “Fiware Labs” specific enabler.

All the GE documentation references KeyRock as the reference Identity Management GE. Therefore we (and i assume others too) have followed the documented architecture and configuration to link to KeyRock from:


Wilma PEP Proxy GE
Wirecloud Application Mashup GE


Because of the inbuilt Fiware Labs functions of KeyRock, we are having a really hard time applying Wilma PEP Proxy and Wirecloud Application Mashup to our use cases. 
If we decide to use Keystone instead, we will lose 


OAuth2 support 
Permissions
sign-up, admin and login screens.


Is anyone else having this problem?
How have they tackled it?

-- SCIM API --

Attempt at using the SCIM API is described here: Fiware KeyRock SCIM API bug: _check_allowed_to_get_and_assign() got an unexpected keyword argument 'userName'


  was:

Created question in FIWARE Q/A platform on 30-04-2016 at 19:04
{color: red}Please, ANSWER this question AT{color} https://stackoverflow.com/questions/36958289/fiware-keyrock-how-to-prevent-fiware-labs-data-being-created-when-a-new-user-re


+Question:+
FIWare KeyRock: How to prevent fiware labs data being created when a new user registers

+Description:+
We want to use the FIWARE IdM, both Keystone and Horizon. Specifically during sign-up we want to


create a user
add that user to an organisation 
authorise the user for an application


We have installed Keystone and Horizon using the latest KeyRock docker image on the docker hub.
When a new user signs up:


a 'cloud organisation' is created. 
By default, the 'provider' and 'purchaser' roles are present 
and the 'Store' application is assigned to the user (although i cannot verify this).
We can add the user to an organisation by hand, and authorise the user for an application by hand in the KeyRock UI.


However this does not make any sense for our local installation.


How can we prevent Horizon from creating the cloud organisation upon user sign-up?
How can we assign a default application authorization upon user sign-up?


-- Edit --

It’s becoming increasingly clear to me that the way KeyRock is implemented is primarily useful for setting up your own Fiware labs environment, as opposed to setting up a generic Identity management service. If we use KeyRock, we will be stuck with cloud organisations, stores etc. Far from being a Generic Enabler (GE), KeyRock seems to be a “Fiware Labs” specific enabler.

All the GE documentation references KeyRock as the reference Identity Management GE. Therefore we (and i assume others too) have followed the documented architecture and configuration to link to KeyRock from:


Wilma PEP Proxy GE
Wirecloud Application Mashup GE


Because of the inbuilt Fiware Labs functions of KeyRock, we are having a really hard time applying Wilma PEP Proxy and Wirecloud Application Mashup to our use cases. 
If we decide to use Keystone instead, we will lose 


OAuth2 support 
Permissions
sign-up, admin and login screens.


Is anyone else having this problem?
How have they tackled it?

-- SCIM API --

Attempt at using the SCIM API is described here: Fiware KeyRock SCIM API bug: _check_allowed_to_get_and_assign() got an unexpected keyword argument 'userName'


     HD-Enabler: KeyRock

> [fiware-stackoverflow] FIWare KeyRock: How to prevent fiware labs data being created when a new user registers
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: HELP-8757
>                 URL: https://jira.fiware.org/browse/HELP-8757
>             Project: Help-Desk
>          Issue Type: Monitor
>          Components: FIWARE-TECH-HELP
>            Reporter: Backlog Manager
>            Assignee: Alvaro Alonso
>              Labels: fiware
>
> Created question in FIWARE Q/A platform on 30-04-2016 at 19:04
> {color: red}Please, ANSWER this question AT{color} https://stackoverflow.com/questions/36958289/fiware-keyrock-how-to-prevent-fiware-labs-data-being-created-when-a-new-user-re
> +Question:+
> FIWare KeyRock: How to prevent fiware labs data being created when a new user registers
> +Description:+
> We want to use the FIWARE IdM, both Keystone and Horizon. Specifically during sign-up we want to
> create a user
> add that user to an organisation 
> authorise the user for an application
> We have installed Keystone and Horizon using the latest KeyRock docker image on the docker hub.
> When a new user signs up:
> a 'cloud organisation' is created. 
> By default, the 'provider' and 'purchaser' roles are present 
> and the 'Store' application is assigned to the user (although i cannot verify this).
> We can add the user to an organisation by hand, and authorise the user for an application by hand in the KeyRock UI.
> However this does not make any sense for our local installation.
> How can we prevent Horizon from creating the cloud organisation upon user sign-up?
> How can we assign a default application authorization upon user sign-up?
> -- Edit --
> It’s becoming increasingly clear to me that the way KeyRock is implemented is primarily useful for setting up your own Fiware labs environment, as opposed to setting up a generic Identity management service. If we use KeyRock, we will be stuck with cloud organisations, stores etc. Far from being a Generic Enabler (GE), KeyRock seems to be a “Fiware Labs” specific enabler.
> All the GE documentation references KeyRock as the reference Identity Management GE. Therefore we (and i assume others too) have followed the documented architecture and configuration to link to KeyRock from:
> Wilma PEP Proxy GE
> Wirecloud Application Mashup GE
> Because of the inbuilt Fiware Labs functions of KeyRock, we are having a really hard time applying Wilma PEP Proxy and Wirecloud Application Mashup to our use cases. 
> If we decide to use Keystone instead, we will lose 
> OAuth2 support 
> Permissions
> sign-up, admin and login screens.
> Is anyone else having this problem?
> How have they tackled it?
> -- SCIM API --
> Attempt at using the SCIM API is described here: Fiware KeyRock SCIM API bug: _check_allowed_to_get_and_assign() got an unexpected keyword argument 'userName'



--
This message was sent by Atlassian JIRA
(v6.4.1#64016)


More information about the Backlogmanager mailing list

You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy   Cookies policy