Open borditamas opened 11 months ago
borditamas
commented
11 months ago At the RoadMap meeting on 13.12.2023, it was suggested that, like ServiceOrchestration (Orchestrator eariler), the Authorization also should be renamed to ServiceAuthorization. Renaming has the advantage of better reflecting the scope of this core system, although authorization of events managed by EventHandler support system falls also under this system's responsibility.
emanuelpalm
commented
10 months ago While token-based authorization is likely going to be desirable in the long run, we at Sinetiq want to make sure these systems initially are a simple they can be. When we have their foundations right, we believe we will be in a much better position to determine what any additional functionality should look like. With this in mind, we want to delay work on token-based authorization.
As far as we understand it, the primary benefit of token-based authorization is that the tokens can be used independently of the authorization service until they expire. A would-be consumer starts by requesting tokens for the services it wishes to consume via the authorization-token service (is this correct @borditamas?). Whenever the consumer actually tries to consume one of those services, it provides the right token with its request. The service provider then validates the token by decoding it and cryptographically verifying its authorship and claims. However, the token verification step is complicated, and it is not obvious to us how it should work.
On the other hand, using the regular authorization service means that a service provider must validate each attempt to consume one of its services by sending a message to the authorization service. The message contains a triplet, consisting of (1) the identity of the consuming system, (2) the name of the service operation being invoked, as well as (3) the identities of the "resources" being targeted by the operation, where a resource could be anything from a configuration setting to a robotic arm.
Focusing on regular authorization first means that we can better prioritize integrating existing access control solutions into Arrowhead, such as Keycloak or Entra ID (formerly Active Directory). In addition, many of these solutions can be configured to produce audit logs (logs of when what access was granted to whom), which we at Sinetiq have understood to be important to our clients (am I wrong, @PerOlofsson-Sinetiq?). If not every access control check is made centrally, then a solution will be needed to robustly gather and compile these audit logs in some other way.
Also, I personally don't believe it to be strictly necessary for the "grant" and "revoke" operations to be part of the "Authorization" service. It only needs to contain a single "authorize" operation through which a provider controls whether or not one of its consumers are allowed to perform one of its operations on a certain set of resources. The management service should suffice for adding access control rules.
@jerkerdelsing @PerOlofsson-Sinetiq @borditamas @AlexChiquito
AlexChiquito
commented
10 months ago Adding to Emanuel's explanation, tokens are particularly useful when leaving the "control" of the centralised trust source (In our case maybe the Core Systems). However, they way that I see it (let me know if Im wrong) is that in an Arrowhead local cloud we do have access to these centralised core systems at all times, so we can make use of them to manage and enforce the authorization policies. In this case we can let each service provider be their own Policy Enforcement Point (PEP), getting authorization decisions from the authorization core system (acting as a central Policy Decision Point (PDP)) for each service call it gets.
Eventually, we could discuss about caching these decisions to improve the performance of the authorization decisions, before having the need of implementing tokens. Moreover, this helps with the revocation of service consumption, as the changes in the policies can be made in runtime, without caring about revoking tokens.
borditamas
commented
10 months ago A would-be consumer starts by requesting tokens for the services it wishes to consume via the authorization-token service (is this correct @borditamas?). Yes it is.
We are agree (at AITIA) that implementing token based authorization mechanism should be done only after the basic auth is working stable.
the identities of the "resources" being targeted by the operation, where a resource could be anything from a configuration setting to a robotic arm.
This resource level authorization would be a completly new feature in arrowhead. I remember that it was mentioned during the NGAC related discussions, but it was also decided that v5.0 should not implement NGAC or something similar solution, so we have not considered using the resource level granuality (operation level at most). Lets discuss it on the next RoadMap meeting.
Grant and Revoke
Grant and revoke being different operations allows the providers to manage its rules incrementally and more conveniently we think. There is also a similar opertaion in the mgmt service (for higher entities) that allows handling rules in bulk.
jerkerdelsing
commented
7 months ago At the RoadMap meeting on 13.12.2023, it was suggested that, like ServiceOrchestration (Orchestrator eariler), the Authorization also should be renamed to ServiceAuthorization. Renaming has the advantage of better reflecting the scope of this core system, although authorization of events managed by EventHandler support system falls also under this system's responsibility.
@borditamas Can you clarify the role of the EventHandler related to authorization?
The Arrowhead community is admonished to read and review the System Description (SysD) of Authorization v5.0 draft, available here:
Please read the document and share your comments and suggestions within this issue.
Antecedent: #63