Message Node Access Control

[pchainho]

Message Nodes should control the access to different resources of the domain. For example, the Policy Engine must not give write access to Domain Registry, to users that are not authenticated as users of the domain.

Can we use Id Tokens generated at the runtime for this purpose?

[jmcrom]

if we consider messaging nodes as gatekeepers for the domain, we should explicitelt state the access control rules

the one aforementioned seems to reqyre an extension to this spec so that idtoken is valid may be used as a condition

[pchainho]

@nuno-santos @Ricardo-Chaves @bouabdal could you provide your feedback pls?

[bouabdal]

I have proposed in D4.4 (cf. D4.4 Fig. 20 p.38 / file joined below) a distributed approach which is the exact opposite of the centralized one advocated by Paulo.

Following my approach, I argue that the main (not all) backend services should own their own policy engine (Discovery / Catalogue / Domain Registry). In the example quoted by Paulo, the task of accepting or rejecting a write access to the Domain Registry should be the responsability of the Domain Registry, the prerogatives of which as much as I know have not been really defined.

We may naturally discuss the pro and the cons of each approach.

To initiate the discussion, I can for example recall the classical virtues of the distributed approach which makes it more reliable and resilient than a centralized one when a failure of variable severity occurs at an entity (the MsgNode for example) or if an entity (the MsgNode for example) is compromised from the security point of view.

The other interesting point to keep in mind concerns privacy which always smells better ;-) in case of a distributed control.

One drawback of the distributed approach is that it requires a more or less kind of synchronization between the different policy engines of the CSP in order to be able to cooperate in an harmonious way. Such a synchronization which looks more like an orchestration than a synchronization is managed by the block "Policy Orchestrator" in the previous schema.

Anyway if we choose the centralized approach where the MesgNode behaves as a GateKeeper, I agree with Jean-Michel that the spec of the policy language description should be extended in order to be able to accept a token as a part of a condition when parsing the rule.

It seems moreover that we should introduce a communication link/inteface between the policy engine and the IdProvider in order to be able to verify the validity of the token.

[pchainho]

@bouabdal I don't advocate any centralised policy framework but a distributed one, similar to the picture you mention above and already discussed in D2.1, if not wrong . Actually, the current implementation is already distributed since we have the Policy Engine developed by INESC in the Runtime and in the MN. As I understand it, this Policy Engine could also work in the Domain Registry or any other reTHINK Functional Entity. Having it just in the MN is a question of optimisation of development resources. But is there anything else implemented in terms of the Policy Framework?

[rjflp]

@pchainho This one passed unnoticed!

For example, the Policy Engine must not give write access to Domain Registry, to users that are not authenticated as users of the domain.

When establishing a connection to another Hyperty, one needs to access the Domain Registry, through the Message Node, for read access. There is no need to authenticate in this situation.

For creating, updating or deleting information from the Domain Registry, the authentication is necessary for access control.

So I guess, authentication should be optional?

[sbecot]

I don't really understand why a user should be authenticated to write in the domain registry. The application (the runtime and/or the messaging node) is responsible to register the live objects/hyperties, not the user himself. If you provide services that allow anonymous communication, it should also work.

[rjflp]

The user only authenticates with the runtime. But the runtime must then "propagate" this information to the message node so that the policy engine can trust the source of each message it processes.

[Ricardo-Chaves]

During the connection between to hyperties the authenticity of each user is already verified.
To read information from the domain register no authentication is needed.
This leaves the need to authenticate/verify the user the hyperty and associated user is written/updated/deleted from the DomainRegister. This verification can be done in the policy engine at the MN. Only allow if the user corresponds to the one authenticated and if it is a write operation ( which can be delete, updated, ... ).
So the remaining issue is how does the MN verify the if the user associated to the hyperty is how he claims to be.

Do you agree?

According to the last discussion in the WP4 meeting, the core RunTime is considered to be somewhat trusted. According to this we could relax the verification of the identity. If the Runtime says it user A then it's user A. Possible attacks (given that the runtime is not so trusted) are minor given that during the connection between hyperties the IDMs verify/validate the IDs.
@sbecot, @jmcrom do you confirm that this was the idea discussed?

[sbecot]

I agree that we should at least trust the msg-node. The runtime has been designed in WP3 to be trusted, and if we want to add a higher level of trust, this shouldn't be at the identity level: the runtime should be a trusted element anyway.