Hi! 2015-07-15 19:04 GMT+02:00 Pablo Fernández Moniz < pablofernandezmoniz at gmail.com>: > Hi! > We have some development progress, and we want to share it and raise some > questions Architecture overview: > > Actually we have an implementation like this. > > > > - > > Represented in white color we have the previous containers that were > in the docker-compose. > - > > mongodb: It stores the database of Orion. It has attached the > mogodbdata volume. > - > > orion: It has the Context Broker installed. It uses the mogodb > image as database. > - > > devguide: It has implemented the API for restaurant management. It > interacts with orion and it acts like an abstraction layer. > - > > Blue elements have been added to the docker compose by the ULPGC group. > - > > idm: It runs an instance of the Identity Management. Users and > roles must be stored here. > - > > authzforce: Image needed by idm. > - > > Finally, elements that have not been added yet to a container are in > yellow. > - > > initUsers.py: It is a python script that creates the first users > and roles in Identity Manager. > - > > flask server: It hosts the web and acts as intermediate layer > between users and the Identity Manager. > > > > > [image: Captura de pantalla 2015-07-15 a las 13.07.42.png] > > Doubts that have arisen > > We need to initialize the IdM with default values ( for example roles ) > so, for the moment, we developed a small python script (initUsers.py) to do > that. > We've been through this already in the image. Few days ago we've updated the documentation of our IdM image with the users, orgs, roles and everything that we've provided. You can find here <https://github.com/Bitergia/fiware-chanchan/blob/master/docker/images/idm-keyrock/4.3.0/keystone.py#L406> the method we've used for that (hope it helps). > > Due to cross domain restriction, we cannot perform petitions directly to > the IdM from the front end. We solved this using an intermediate layer in > the server that controls the user creation and the login . Another solution > could be to use a proxy. > Furthermore, in order to allow users to sign up, we need an administrative > credential to create the new user entity. If this credential is used from > the front end, it could be a security risk. So, we think that the actual > approach of managing the operations related to the IdM from the server side > is correct. > The PEP Proxy could be the intermediate layer to handle this access. The approach could be, an administrator that is able to handle users, organizations, roles and permissions. Then, create different roles, allowing just the administrator to use requests for user administration using the Keystone API <http://developer.openstack.org/api-ref-identity-v3.html#users-v3>. We've updated today also the PEP Wilma image and documentation: https://registry.hub.docker.com/u/bitergia/pep-wilma/ Doing this, we include another GE to the architecture proposed :) > > On the other hand, we have started to make some development in the server > side. We are using python since we have experience with it and we have had > good results using it. We also have good feelings with other languages such > as PHP. > > > I personally feel more comfortable with python, but I cannot speak from the others. > We don’t know which language are you using at this moment, but we think > that the less different languages we use the better for making an easy > guide. > Actually we've been using javascript (node, angular) for the application, shell scripts and a bit of python. > > Finally, we suggest that we should add a new image that contains the web > server. > What do you need for the web server exactly? In the fiware-devguide-app <https://registry.hub.docker.com/u/bitergia/fiware-devguide-app/> we have already an apache2.4 with phusion passenger, and it teorically supports node, ruby and python. If something like that is enough, we can create a clean container with this for start deploying the web server. > > What do you think? > Looks good! We will also have to add IDAS, and other components (as the PEP proxy mentioned before), but step by step :) > > KR, and sorry for the large email :) > > > ULPGC team > > > Cheers, Alberto Martín > -- > > Pablo Fernández Moniz > GIT Analyst > > Web <http://www.pablofm.com> Linkedin > <http://www.linkedin.com/in/pablofernandezmoniz/> Twitter > <http://www.twitter.com/monizpablo> > > _______________________________________________ > Fiware-developer-experience mailing list > Fiware-developer-experience at lists.fiware.org > https://lists.fiware.org/listinfo/fiware-developer-experience > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.fiware.org/private/fiware-developer-experience/attachments/20150715/e9a8c071/attachment.html>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy