A REST mellett döntöttünk. Mind a *portal* mind az *interface* publikál egy REST API-t. Ez egyszerűen megvalósítható. Jó kiindulási pont.
A REST mellett döntöttünk. Mind a *portal* mind az *interface* publikál egy REST API-t. Ez egyszerűen megvalósítható. Jó kiindulási pont.
### Authentikáció, authorizáció
### Authentikáció, authorizáció
Az authentikációra az OpenStack tartalmaz egy modult a Keystone-t. Ez egy jól specifikált és implementált modul, ám a céljainknak nem felel meg tökéletetes.
Az authentikációra az OpenStack tartalmaz egy modult a Keystone-t. Ez egy jól specifikált és implementált modul, ám a céljainknak nem felel.
Problémák:
__Problémák__
* Használatával megsértenénk azt a követelményt, hogy több Cloud Manager-t is támogasson a rendszer.
* Használatával megsértenénk azt a követelményt, hogy több Cloud Manager-t is támogasson a rendszer.
* Nem minden művelet végezhető el benne a jogosultságokkal kapcsolatban úgy, ahogy a mi üzleti logikánkban szerepel. (Szabolcsnál felmerült: nehéz a CIRCLE user-ek mappelése a keystone-os user fogalomhoz )
* Nem minden művelet végezhető el benne a jogosultságokkal kapcsolatban úgy, ahogy a mi üzleti logikánkban szerepel. (Szabolcsnál felmerült: nehéz a CIRCLE user-ek mappelése a keystone-os user fogalomhoz)
__Döntés__
Saját authentikációt és authorizációt készítünk. Az OpenStack-es hívásokat egy projekthez tartozó admin user segítségével végezzük. Így nagy szabadságunk lesz a különböző userek jogainak meghatározásában.
Fontos, hogy mind a portal mind az interface authentikál. Az authorizációt a portal végzi.
### Hálózat és NAPT
Az OpenStack jelenlegi tudásunk szerint nem támogatja a NAPT-ot abban a formában, ahogy mi szeretnénk (1:portA -> n:portB). Amit tud az az nA:portA -> nB:portB. Ezért szükséges egy újabb hálózati réteg bevezetése.
