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.

[jmcrom]

what is the status of this issue?

[rjflp]

It is dependent on this one

[Ricardo-Chaves]

@sbecot the Runtime is trusted to the user, but it is not to external entities. The Message Node (MN) and Global Registry (GR) do not/should not trust the runtime.

To assure that only rightful users register hyperties on that user's behalf it must prove to be that user, using the correct IDToken.

The suggestion is for the runtime to prove to be acting on behalf of that user to the MN (trusted by the respective DR). Thus, if the MN checks the ID, the DR can trust it to be from that specific user. In this case the Runtime should validate it sends the IDToken to a rightful MN (for example by checking the MN certificate at the TLS connection).

If this validation is not preformed, any one can register hyperties associated to any ID in the DR. This will allow for an attacker to pollute the DR. A possible attack is an attacker constantly registering an hyperty on my behalf , not allowing anyone to see my rightful hyperty registration at the DR (since it is always being replaced by the bad one from the attacker).

In any case when hyperties connect, the claimed IDs are checked and the connection is not establish if a wrong ID is claimed.