IDD 5.0 review discussion - Authorization Management

[AlexChiquito]

n this Issue we will collect the comments about the authorization-management-http-json interface definition.

[emanuelpalm]

Link to reviewed document: eu.arrowhead.authorization-management-http-json.yml.

[borditamas]

AITIA review comments

• The IDD should use the Arrowhead terminology (consumer, provider, service etc...) instead of NGAC (subject, resource, user-attributes, association etc...) terms. The implementation itself can be NGAC, but this shouldn't be visible in the service interface level. To being inline with the goal of "lowering the entry steps", the interface should be way more simple to understand and use we think.
• There should be only 3 operation. Bulk grant, bulk revoke and bulk validation.
• Too much type of 4xx response codes are used. 400, 401, 403 should be enough for the sake of simplicity.
• Event types not considered by this IDD.

---

We believe that the NGAC concept is way more general than what Arrowhead needs at this point. Of course under the hood an implementation could use an NGAC engine but Arrowhead authorization should not be bounded to the general NGAC concept.

We think that Arrowhead 5.0 should support the following policies/rules:

• consumer can use a specific provider's service
• consumer can use a specific provider's service operation
• consumer can use a specific provider's service operation on a specific resource (eg. file)
• (subscriber can receive specific publisher's event with a specific type)
• instead of a specific consumer we can use various wildcards (like everybody, everybody in a cloud, everybody in a whitelist, everybody that not on a blacklist)

---

https://github.com/eclipse-arrowhead/roadmap/blob/5a4f4b2d3149288a48bda69337f7e041a05d0161/5.0%20Draft/IDD/IDDs%20Authorization%20System/eu.arrowhead.authorization-management-http-json.yml#L41 "ping" (or echo) operation should not be part of this service, but a different "monitor" service.

[borditamas]

@AlexChiquito @emanuelpalm @PerOlofsson-Sinetiq Could you please provide Sinetiq's feedback before the next RoadMap (05.02) in order to being able to discuss it there? As you know, last time the 14th of May (before AIMS 5.0 GA) was agreed to target the specification being finalized, so we don't have so much time.

[emanuelpalm]

• The IDD should use the Arrowhead terminology (consumer, provider, service etc...) instead of NGAC (subject, resource, user-attributes, association etc...) terms. The implementation itself can be NGAC, but this shouldn't be visible in the service interface level. To being inline with the goal of "lowering the entry steps", the interface should be way more simple to understand and use we think.

@borditamas

I agree, to the extent where the concept we are working with maps to an Arrowhead concept.

See also:

• https://github.com/eclipse-arrowhead/roadmap/issues/81#issuecomment-2127209414
• https://github.com/eclipse-arrowhead/roadmap/issues/81#issuecomment-2127245440
• https://github.com/eclipse-arrowhead/roadmap/issues/81#issuecomment-2127260662

[emanuelpalm]

• There should be only 3 operation. Bulk grant, bulk revoke and bulk validation.

If we can get it down to that, I'd be happy. :)

[emanuelpalm]

• Too much type of 4xx response codes are used. 400, 401, 403 should be enough for the sake of simplicity.

I agree.

[emanuelpalm]

• Event types not considered by this IDD.

How would they fit in this IDD?

[emanuelpalm]

We believe that the NGAC concept is way more general than what Arrowhead needs at this point. Of course under the hood an implementation could use an NGAC engine but Arrowhead authorization should not be bounded to the general NGAC concept.

We think that Arrowhead 5.0 should support the following policies/rules:

• consumer can use a specific provider's service
• consumer can use a specific provider's service operation
• consumer can use a specific provider's service operation on a specific resource (eg. file)
• (subscriber can receive specific publisher's event with a specific type)
• instead of a specific consumer we can use various wildcards (like everybody, everybody in a cloud, everybody in a whitelist, everybody that not on a blacklist)

All of these use cases should be possible with the triplets we have proposed. I need to look in more detail at this IDD to be able to tell if it can facilitate all of them, however.

[emanuelpalm]

https://github.com/eclipse-arrowhead/roadmap/blob/5a4f4b2d3149288a48bda69337f7e041a05d0161/5.0%20Draft/IDD/IDDs%20Authorization%20System/eu.arrowhead.authorization-management-http-json.yml#L41 "ping" (or echo) operation should not be part of this service, but a different "monitor" service.

I agree.

[AlexChiquito]

We believe that the NGAC concept is way more general than what Arrowhead needs at this point. Of course under the hood an implementation could use an NGAC engine but Arrowhead authorization should not be bounded to the general NGAC concept.

We think that Arrowhead 5.0 should support the following policies/rules:

• consumer can use a specific provider's service
• consumer can use a specific provider's service operation
• consumer can use a specific provider's service operation on a specific resource (eg. file)
• (subscriber can receive specific publisher's event with a specific type)
• instead of a specific consumer we can use various wildcards (like everybody, everybody in a cloud, everybody in a whitelist, everybody that not on a blacklist)

All of these use cases should be possible with the triplets we have proposed. I need to look in more detail at this IDD to be able to tell if it can facilitate all of them, however.

What I tried to propose is rather the "Attribute-based" concept, as otherwise having object-level authorization may become a mess just with rules. The triples that are considered in the IDD can cover those use cases, except that is always with the use of attributes, or wildcards.

For rules such as:

consumer can use a specific provider's service

We must have the consumer be part of an attribute, and the service be part of another attribute, and that a rule exists between them. It can be possible to add the possibility of expressing rules for subject-resource access in addition to attribute-rules, if really needed. We can discuss that.