Hi all! El mié, 15-07-2015 a las 20:35 +0200, Alberto Martín Casado escribió: > 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. > > > > > > > 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 the method we've > used for that (hope it helps). I think the best approach is that you don't need to work in this provision for users, roles, organizations and others. We need to share a common view here and we can implement the provision as Alberto said. > > > 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. We offer an auth API REST in the same server where you download the client, so this kind of problems won't appear if you use it in tour client. > > > 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. Yes, I think so. > > > > > 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. 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 :) I am not sure I am understanding right this proposal. IMHO we can: * Provision initial users, roles, organizations, applications and others. * Offer and API REST so already provided users can authenticate and get the tokens for accessing the service. * The petitions to the service will be routed through PEP Wilma (we can do it later) in order to check permissions. > > > 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. In my imaged architecture, you don't need any server development. We will offer you a REST API so you can just work client side consuming it. Pablo, what do you think? It is the approach followed in chanchan. Attached a file with chanchan current arch. > > 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. All our work as Alberto said is implemented using Javascript to simplify the environment. Some minor scripts are in Python, but it is not the "core". > > > 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 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. > In my mind I image you deploying your client in the current devguide docker image, in the directory: https://github.com/Bitergia/fiware-devguide-app/tree/master/client and it will be served by the same apache server alberto commented above. > > 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 :) Probably you don't need to play directly with other componentes/GEs. We can complete the REST API with your client needs. Cheers > > > KR, and sorry for the large email :) > > > ULPGC team > > > > > > > > Cheers, > > > > > > > Alberto Martín > > > -- > > Pablo Fernández Moniz > > GIT Analyst > > > Web Linkedin Twitter > > > _______________________________________________ > Fiware-developer-experience mailing list > Fiware-developer-experience at lists.fiware.org > https://lists.fiware.org/listinfo/fiware-developer-experience > > > > _______________________________________________ > Fiware-developer-experience mailing list > Fiware-developer-experience at lists.fiware.org > https://lists.fiware.org/listinfo/fiware-developer-experience -- Alvaro del Castillo San Félix acs at bitergia.com - Chief Technical Officer (CTO) http://www.bitergia.com "Software metrics for your peace of mind" -------------- next part -------------- A non-text attachment was scrubbed... Name: ChanChanArchDocker.pdf Type: application/pdf Size: 26350 bytes Desc: not available URL: <https://lists.fiware.org/private/fiware-developer-experience/attachments/20150716/65fd8599/attachment.pdf>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy