IDD 5.0 review discussion - Authorization

[AlexChiquito]

In this Issue we will collect the comments about the Authorization-http-json interface definition.

[emanuelpalm]

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

[borditamas]

AITIA review comments

• The IDD should use the Arrowhead terminology (consumer, provider, service etc...) instead of general (subject, resource etc...) terms.
• Too much type of 4xx response codes are used. 400, 401 should be enough for the sake of simplicity.

---

roadmap/5.0 Draft/IDD/IDDs Authorization System/eu.arrowhead.authorization-http-json.yml

Line 64 in 5a4f4b2

/ping:

"ping" (or echo) operation should not be part of this service, but a different "monitor" service.

---

roadmap/5.0 Draft/IDD/IDDs Authorization System/eu.arrowhead.authorization-http-json.yml

Line 72 in 5a4f4b2

/authorizations:

• Bulk authorization should be part of management service and not this service. Provider gets one request a time and it wants to check that consumer and can't wait for more to authorize them at once.
• Missing grant and revoke operations (for ordinary providers). We should allow the providers to specify its own authorization policies/rules.
• Why "Address" appears here within the schemas?
• Event types not considered by this IDD

[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 general (subject, resource etc...) terms.

@borditamas

• I agree that subject should be replaced with consumer.
• I think access-right is a bit clunky, mainly because it's such a long word. I can't really think of a better word, however. We can't use operation or service, because it doesn't map only to those concepts. Some typical "access rights" are likely to be read, write, drop, replace and register. One "access right" can be reused across multiple services, and individual operations can use several of them (even though it may be a bad idea in many cases). In Keycloak it's referred to as a scope, while it is generally referred to as a verb in access control literature, or as a predicate in RDF literature. I'd vote for scope because it's short.
• resource is also hard to replace, because a resource can be a file, a robot arm, temperature sensor, or a service provider. It really depends on how you decide to specify your access control rules.

Did I miss any other terms?

[emanuelpalm]

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

I agree. Specifying what subset of response codes could be returned may be important for implementations on constrained systems, which is why I added them in the draft that @AlexChiquito reshaped into its current form. As we don't have any concrete constrained use cases yet, we can just assume complete HTTP compliance and get rid of most of them.

[emanuelpalm]

roadmap/5.0 Draft/IDD/IDDs Authorization System/eu.arrowhead.authorization-http-json.yml

Line 64 in 5a4f4b2

/ping:

"ping" (or echo) operation should not be part of this service, but a different "monitor" service.

I personally agree. I'm not sure I have Sinetiq behind me, however.

[AlexChiquito]

Hi!

• For Bulk Authorizations: #

AITIA review comments

• The IDD should use the Arrowhead terminology (consumer, provider, service etc...) instead of general (subject, resource etc...) terms.

• I agree that subject should be replaced with consumer.
• I think access-right is a bit clunky, mainly because it's such a long word. I can't really think of a better word, however. We can't use operation or service, because it doesn't map only to those concepts. Some typical "access rights" are likely to be read, write, drop, replace and register. One "access right" can be reused across multiple services, and individual operations can use several of them (even though it may be a bad idea in many cases). In Keycloak it's referred to as a scope, while it is generally referred to as a verb in access control literature, or as a predicate in RDF literature. I'd vote for scope because it's short.
• resource is also hard to replace, because a resource can be a file, a robot arm, temperature sensor, or a service provider. It really depends on how you decide to specify your access control rules.

Did I miss any other terms?

• I am particularly agains having consumer as the subject, as that reduces the entire scope of the authorization to just service consumptions. In other words, it is limiting the function of the whole service just by a choice of words, even if the main purpose is for service consumption authorizations.
• I agree that access-right is a very academic term. My vote also goes for scope.
• For resource I have the same argument as for subject. Particularly if there is the ambition of having a object-level authorization.

[emanuelpalm]

roadmap/5.0 Draft/IDD/IDDs Authorization System/eu.arrowhead.authorization-http-json.yml

Line 72 in 5a4f4b2

/authorizations:

• Bulk authorization should be part of management service and not this service. Provider gets one request a time and it wants to check that consumer and can't wait for more to authorize them at once.

What if a certain service operation acts on more than one resource? Isn't it convenient if we can check if access is allowed to all of those resources at once?

[emanuelpalm]

• Missing grant and revoke operations (for ordinary providers). We should allow the providers to specify its own authorization policies/rules.

I'm not sure I understand this comment. Do you mean operations for granting new or revoking existing access tokens? Why should that be part of this API?

[emanuelpalm]

• Why "Address" appears here within the schemas?

It seems to be a mistake.

[emanuelpalm]

• Event types not considered by this IDD

Why would they be considered by this IDD? Do you mean that events should be published every time an authorization rule changes?

[emanuelpalm]

• I am particularly agains having consumer as the subject, as that reduces the entire scope of the authorization to just service consumptions. In other words, it is limiting the function of the whole service just by a choice of words, even if the main purpose is for service consumption authorizations.

@AlexChiquito What other thing in an Arrowhead context could be the subject of an authorization? The term consumer is used to refer to both machines and humans consuming services. If there is anything else that could consume them, I agree with your comment.

[AlexChiquito]

• Bulk authorization should be part of management service and not this service. Provider gets one request a time and it wants to check that consumer and can't wait for more to authorize them at once.

I agree that if we limit the authorization system to just service consumption, then the scenario is true. But for object-level auhtorization, a single service consumption request may mean multiple Authorization checks. Such as checking whether a Subjectis allowed to deletea record before trying to write a new one, for example.

• Missing grant and revoke operations (for ordinary providers). We should allow the providers to specify its own authorization policies/rules.

Shouldn't that be part of the authorization management service? Or maybe I am missing something

[AlexChiquito]

• I am particularly agains having consumer as the subject, as that reduces the entire scope of the authorization to just service consumptions. In other words, it is limiting the function of the whole service just by a choice of words, even if the main purpose is for service consumption authorizations.

@AlexChiquito What other thing in an Arrowhead context could be the subject of an authorization? The term consumer is used to refer to both machines and humans consuming services. If there is anything else that could consume them, I agree with your comment.

Maybe I am being too ambitious with the Authorization System, but... for example, if a service to read a database contains user credentials, one may want to use the Authorization System to both verify that the consumer can consume the database service, but also that the user credentials are allowed to perform that certain operation over a table in the database. However, the second operation would not make sense as Consumer does not really match with what a user credential means to a database. But Im open for discussion.

[emanuelpalm]

Maybe I am being too ambitious with the Authorization System, but... for example, if a service to read a database contains user credentials, one may want to use the Authorization System to both verify that the consumer can consume the database service, but also that the user credentials are allowed to perform that certain operation over a table in the database. However, the second operation would not make sense as Consumer does not really match with what a user credential means to a database. But Im open for discussion.

That's a good enough argument for me.

[jerkerdelsing]

Consumer and producer terminology to be used.
Error codes 400, 401, etc Tamas and Alex to make a proposal.
Raymond and Alex to agree on the way forward on authorization and authorization_management.

[borditamas]

Missing grant and revoke operations (for ordinary providers). We should allow the providers to specify its own authorization policies/rules.

I'm not sure I understand this comment. Do you mean operations for granting new or revoking existing access tokens? Why should that be part of this API?

@emanuelpalm Not related to tokens. There should be an operation where an ordinary provider cloud define by its own which consumers can use its service operations.

Event types not considered by this IDD

Why would they be considered by this IDD? Do you mean that events should be published every time an authorization rule changes?

@emanuelpalm No. The Event Handler should only notify a subscriber about an event if such a subscriber has rights to receive that specific event type from that specific publisher. The version 4.x takes service authorization rules into consideration even if a subscriber is not consuming any service, just wants receive the events.

[borditamas]

Consumer and producer terminology to be used.
Error codes 400, 401, etc Tamas and Alex to make a proposal.
Raymond and Alex to agree on the way forward on authorization and authorization_management.

The outcomes of the Sinetiq-Aitia (Alex, Rajmund, Tamás) discussion are attached:
authorization services AH5 proposal.pdf
Http status codes AH5 proposal.pdf

[jerkerdelsing]

The HTTP status code suggestion by AITIA and Sinetiq was accepted by the Roadmap WG meeting 240618, please implement in the currently available IDD's

[jerkerdelsing]

The priority to management authorization rules over individual microsystem authorization rules shall be introduced in to the GSoSD, document. Jerker to do this. The suggestion by AITIA and Sinetqiq should be introduced into the Authorization SysD, SysDD, SD, IDD documents.