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.

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

5. FIWARE Community
5
http://map.fiware.org/

6. FIWARE Lab
6
http://infographic.lab.fiware.org/

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

14. OAuth2
14
Cloud Portal
OAuth2
Keyrock

15. OAuth2
15
Cloud Portal
OAuth2
Keyrock
Keystone TOKEN TOKEN

16. Google Account
16

17. FIWARE Account
17
Account

18. FIWARE Account
Login with

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

28. FIWARE Lab Accounts
Basic
Trial
Community
1
2
4
3
5
6
7

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