WIS node authorization requirements

[kurt-hectic]

Some WIS nodes have expressed their desire to implement ACLs. A WIS node may want to restrict access to its broker and/or web-storage components due to security or data-policy reasons. For this the identity of the subscribing/downloading entity needs to be established so that the node can implement ACLs.

A common authentication schema across WIS reduces cost and improves security, as less credentials need to be kept and methods implemented.

It is proposed that a Global Registry service maintain the required security metadata.

This issue is created to track ACL requirements and to discuss possible solutions.

requirements

• a WIS node would like to limit the exposure of its broker and web-storage to only (some) GB/GB on network level.
• a WIS node would like to use the same broker and web-storage to publish both core and restricted data and needs a mechanism to limit access to the restricted data on protocol level (MQTT and/or HTTP)
• a WIS node would like to use TLS to protect authentication credentials
• a WIS node would like to periodically change credentials
• a WIS node may require use of credentials access to its broker or web-storage (and not accept publicly-known credentials set by convention).

non-functional requirements

• the schema should be standards-based and compatible with MQTT and HTTP
• the same schema should be used for broker and web-storage
• WIS should have a limited operational dependency on the Global Registry (run x days without it)
• the schema should not limit the implementation choice of WIS nodes

analysis

Solutions should be analyzed in terms of

• degree to which they meet the requirements
• operational impact on WIS
  • A suitable metric could be the number of yearly changes across WIS as a consequence of security metadata (credentials) updates
• security
  • degree of exposure of Global Registry (read-only, write, online or offline).
  • impact if compromised
  • proprietary agents needed?
• cost
  • license cost
  • cost of providing security metadata (credentials) management service as part of Global Registry

discussion

Modifying the requirements can impact the scope of solutions. For example, if the schema were to be used for HTTP only (and MQTT access open), there would be a larger number of potential authentication schemas.
If the scope of the schema were limited to core data, nodes requiring security would only have to implement network level ACL without the need for protocol level identities and the consequent need for the Global Registry to maintain additional security related metadata.

Are there other authorization requirements?

[kurt-hectic]

In the pilot-phase, source IP filtering of GC/GB IP addresses by a local firewall, and username/password authentication have been implemented.

Source IP filtering

• GBs and GCs maintain outgoing IP addresses used in the Global Registry
• WIS nodes can obtain this list of IP addresses and implement firewall rules
• There is a protocol to communicate updates to WIS nodes avoiding / minimizing downtime

+ network level protection
+ little operational impact, as IPs chance rarely
- cannot be used to manage access to restricted data
- GB/GC cannot freely manage their network

Username and Password

• WIS nodes create a username/password (possibly one for each GC and GB)
• local ACLs (in broker or web-storage) implemented based on username
• credentials are maintained in Global Registry
• GC and GB use user/pass for MQTT subscribe and HTTP auth
• There is a protocol to communicate updates to GB/GC avoiding / minimizing downtime

+ can be used for MQTT and HTTP
+ can be used to manage access to restricted data
- high number of credentials (~ nr nodes * (GB+GC) ) and expected changes
- high exposure of Global Registry

Certificates

Certificates have also been discussed.

• Global Registry issues certificates to GB/GC
• GB/GC submit client certificates when making TLS connections to WIS nodes
• WIS nodes implement ACL based on client certificate

+ PKI requires no prior credentials exchange and low number of certificates (nr GB + nr GC)
+ PKI not exposed to the internet
- cannot be used to manage access to restricted data
- community has no experience with PKI
~ kind of works with MQTT and HTTP (ACL implemented on TLS, not MQTT or HTTP level)

[josusky]

I can see that for WIS2 nodes login/password is the easiest solution but I also understand that from the perspective of the global services this can be hard to manage.
I tend to prefer the solution with certificates, therefor I will add one "+" point for it (Edit: or rather remove one "-"):

• we want to use TLS based protocols anyway, there is no real reason to take into consideration the plain MQTT and HTTP.

[kaiwirt]

What has been observed in the wild is

IP Source Filtering
Bearer Authentication
Username / Password

I also like Certificate based authentication (given, that we do not run our own CA which would be a no-go for me).

The question is do we want to (or can we even) limit the set of authentication mechanisms. I think we can ask to use standards (that is http or https for example). But if someone wants to implement HTTP Basic Authentication with username / password can we say this is not possible?

My point of view is, that we (DWD) tried to reuse existing components. So at least the DWD data server has been in place and is reused for WIS2. However we do not implement TLS Client Certificate checking there. Having this as a MUST would therefore require that we host another data server just for that purpose.

To cut a long story short i would prefer to state "Follow the standard" as a MUST. Specify client certificates as a SHOULD. And allow Bearer Authentication, Source IP Filtering and Username / Password as a CAN.

OpenAPI even allows yet again additional methods: https://swagger.io/docs/specification/authentication/
The http schemes can be found here: https://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml

[golfvert]

Decision on this issue will be part on the guide. I fully agree with @kaiwirt

[tomkralidis]

Note that in WCMP2 we support describing security in the context of a link having an optional security object based on the OpenAPI security schemes.

[efucile]

Decision

Only IP address filtering will be offered to authenticate a GB and GC from the WIS2 node and provide access. Implementing user/password will be considered when the requirement is made.