KeyRock and Wilma - Openstack-based Identity Management in FIWARE
Download as PPTX, PDF1 like1,103 views
This document discusses KeyRock and Wilma, which provide identity management and authorization in FIWARE. KeyRock is based on OpenStack's Horizon and Keystone and provides user registration, authentication, and authorization. Wilma acts as a PEP proxy, enforcing access policies defined in AuthZForce. Together, they allow secure authentication of users and authorization of access to FIWARE services and applications.
KeyRock and Wilma - Openstack-based Identity Management in FIWARE
- 1. KeyRock and Wilma Openstack-based Identity Management in FIWARE Joaquín Salvachúa - Álvaro Alonso jsalvachua@dit.upm.es - aalonsog@dit.upm.es
- 2. FIWARE FIWARE is an innovative, open cloud-based infrastructure for cost-effective creation and delivery of Future Internet applications and services, at a scale not seen before. These APIs are public and royalty-free, driven by the development of an open source reference implementation which accelerates the availability of commercial products and services based on FIWARE technologies. More in • https://www.fiware.org • /https://www.fiware.org/formation 2
- 3. FIWARE Generic Enablers Generic Enablers (GE) offer a number of general-purpose functions, offered through well-defined APIs, easing development of smart applications in multiple sectors. They will set the foundations of the architecture associated to your application. Specifications of FIWARE GE APIs are public and royalty-free. You can search for the open source reference implementation, as well as alternative implementations, of each FIWARE GE in the FIWARE Reference Architecture. 3
- 4. 4
- 7. FIWARE Lab & Cloud 7 Region 1 OS Service Region 2 OS Service Region n OS Service Cloud Portal Keyrock DB getCatalogue
- 8. FIWARE Lab & Cloud 8 Region 1 OS Service Region 2 OS Service Region n OS Service Cloud Portal Keyrock DB request (token)
- 9. FIWARE Lab & Cloud 9 Region 1 OS Service Region 2 OS Service Region n OS Service Cloud Portal Keyrock DBvalidate (token) :service credentials
- 10. FIWARE Lab & Cloud 10 Region 1 OS Service Region 2 OS Service Region n OS Service Cloud Portal Keyrock 2 DB Keyrock 1 HA Proxy
- 11. Keyrock architecture Horizon • Fron-end component • User views Keystone • Back-end component • Resources management • Connection to data base Horizon Keystone DB
- 12. Horizon extensions Openstack Horizon FIWARE UI AuthZForce Driver OAuth2 Driver FIWARE Accounts Admin tools reCaptcha
- 13. Keystone extensions Openstack Keystone Keystone API SCIM 2.0 User Registration Two factor auth OAuth2
- 19. OAuth2 External applications 19 Cloud Portal Keyrock App 1 App 2 OAuth2 OAuth2OAuth2
- 20. Token validation 20 Cloud Portal OAuth2 Keyrock Keystone TOKEN Region 1 OS Service Keystone Middleware TOKEN Validation
- 21. Token validation External Applications 21 App OAuth2 Keyrock Keystone TOKEN Backend service Wilma TOKEN Validation
- 22. Wilma Backend Service REST API REST Client Other services HTTP request Web App User 1 User 2
- 23. Wilma Backend Service REST API REST Client Other services HTTP request + TOKEN Web App Wilma User 1 User 2
- 24. Authentication Backend Service REST API HTTP request + TOKEN Wilma User Keyrock GE TOKEN OK + user info
- 25. Authorization Backend Service REST API HTTP request + TOKEN Wilma User Keyrock GE AuthZForce GE
- 26. AuthZForce The other part in Policy Management Wilma PEP • Policy Enforcement Point AuthZForce PAP & PDP • Policy Administration Point • Policy Decision Point 26
- 27. FIWARE Lab Accounts Basic • Manage organizations • Register applications • Use Cloud if other users authorize him Trial • Cloud 14 days Trial period Cloud Project • Spain2 region Community • Cloud during 9 months Cloud Project • Assigned region
- 29. Private Regions Support Goal • Support to private regions that wants to offer part of their Cloud resources to FIWARE Lab users 29
- 30. The scenario • FL user represent a user with a registered account in FIWARE Lab • In FIWARE Lab environment, FL OS Services represent the services of all the Federated nodes • Private Cloud is a Commercial Cloud Provider that wants to offer some of its resources (part of Local OS Services) to be available in FIWARE Lab as a new node. • Private Cloud has their own users registered in its local Keystone (Ext User is one of them) and using Cloud resources deployed in Local OS Services Keyrock Cloud Portal FIWARE Lab FL OS Services FL User Keystone Horizon Private Cloud Local OS Services Ext User
- 31. Requirements • Ext User can continue using his deployed resources in Local OS Services using Horizon • FL User (if he has the correct rights) can deploy resources in Private Cloud Local OS Services using Cloud Portal • In Cloud Portal, Private Cloud node appears as a new node. It is accessible for FIWARE Lab users with quotas in that node (community users assigned to that node) • Private Cloud infrastructure owners can assign quotas of Local OS Services to FIWARE Lab users (to their cloud projects) • FL User can continue using FL OS Services as before. • If a Ext User wants to use FIWARE Lab nodes resources, he has to create an account in FIWARE Lab. Keyrock Cloud Portal FIWARE Lab FL OS Services FL User Keystone Horizon Private Cloud Local OS Services Ext User
- 32. Solution – FL User using FIWARE Lab resources Everything works as always 1. Cloud Portal authenticates the user in Keyrock 2. Cloud Portal sends a request to an OS Service 3. OS Service validates the token with Keyrock Keyrock Cloud Portal FIWARE Lab FL OS Services FL User Keystone Horizon Private Cloud Local OS Services Ext User 1 2 3
- 33. Solution – Ext User using Local resources Everything works as always 1. Horizon authenticates the user in Keystone 2. Horizon sends a request to an OS Service 3. OS Service validates the token with Keystone Keyrock Cloud Portal FIWARE Lab FL OS Services FL User Keystone Horizon Private Cloud Local OS Services Ext User 1 2 3
- 34. Solution – FL User using Private Cloud resources 1. Cloud Portal authenticates the user in Keyrock 2. Cloud Portal sends a request to a Private Cloud OS Service 3. Private Cloud OS Service tries to validate the token in Keystone 4. As the validation doesn’t success (the token is not stored in Keystone), Keystone validates it with Keyrock acting as a gateway and sending the response to Private Cloud OS Service *. If the validation success, Keystone stores the token locally (in cache), so the next times the step 4 is not required. Keyrock Cloud Portal FIWARE Lab FL OS Services FL User Keystone Horizon Private Cloud Local OS Services Ext User 1 2 4 3 Token driver
- 35. IoT Support
- 36. Context Broker Sensor authentication update / query Context Producer / Consumer PEP Proxy Keyrock GE Token creation Token validation
- 37. Conclusions Evolution and integration between OpenStack and a IDM. Evolution in Open Source (development by UPM in the proyect). Identity solution widely used among all the startups ( Most used GE ). Goal to have it integrated in different susteniable ecosystems: • Full integration with OpenStack. 37
- 38. Important Links FIWARE • https://www.fiware.org/ FIWARE Lab • https://account.lab.fiware.org/ Keyrock • http://catalogue.fiware.org/enablers/identity-management-keyrock Wilma • http://catalogue.fiware.org/enablers/pep-proxy-wilma AuthZForce • http://catalogue.fiware.org/enablers/authorization-pdp-authzforce 38
- 39. Opensource projects Keyrock • https://github.com/ging/fiware-idm • Horizon fork: https://github.com/ging/horizon • Keystone fork: https://github.com/ging/keystone Wilma • https://github.com/ging/fiware-pep-proxy AuthZForce 39
- 40. KeyRock and Wilma Openstack-based Identity Management in FIWARE Joaquín Salvachúa - Álvaro Alonso jsalvachua@dit.upm.es - aalonsog@dit.upm.es