Bugs in Client Channel references

[mike1813]

During extensions to add support for key vaults and additional OIDC-style flows, a new base class of domain#ClientChannel was added, called domain#AuthChannel. This is used when a client-service relationship exists through an authorization flow, so the service is verifying authorization tokens from or representing the client (i.e., they have a trust relationship), but not authenticating the client.

ClientChannel assets may be direct (where the client and service communicate directly with each other) or indirect (where communication goes via one or more intermediaries). In the latter case, the intermediaries forward client authentication credentials, so they 'impersonate' the client. The client and service have an authentication relationship. An AuthChannel asset cannot be direct, and arises where the service verifies access tokens from the client to make access control decisions, but authenticates the direct client.

Threats to client-service relationships and data flows over (direct and indirect) client-service connections were then overhauled, and any references to Client Channels were changed to Auth Channels where appropriate. However:

• some threats were missed, most notably some 'normal operational' processes, and
• some construction patterns were not reviewed to check whether they should now refer to AuthChannels.

Returning to this, some pattens need to be revisited.

Roles filled by 'ClientChannel' assets are OK where the role has a link to another asset that can only exist if the client-service relationship is direct. Specifically:

• only a ClientChannel (not an AuthChannel) can have a 'channelVia' link to a ServiceChannel asset
• only a ClientChannel (not an AuthChannel) can have a 'flowsViaCS' or 'flowsViaSC' relationship from a DataStep asset

This leaves a few construction patterns to be checked, where a role is currently specified to be fulfilled by a ClientChannel but may also need to allow matches to AuthChannel assets:

• [x] CCCvCCvLS+vLS, role ClientChannel: is not a direct relationship and should be changed to the base class AuthChannel
• [x] CCCtCCS+aTS+aTS, role ProxyChannel: is not a direct relationship and should be changed to the base class AuthChannel.
• [x] CCCfCCS+aFC+aFC, role ProxyChannel: is not a direct relationship and should be changed to the base class AuthChannel.
• [x] CCCvCCvLS+vLS, role ProxyChannel: is OK because indirect channels are not yet linked to logical subnets.
• [x] CCCSPSFCS+f, role FirstChannel: is OK because data flows are not yet linked to indirect channels.
• [x] CCCSPSFCS+f, role ProxyChannel: is OK because data flows are not yet linked to indirect channels.
• [x] CCCSPSFSC+f, role FirstChannel: is OK because data flows are not yet linked to indirect channels.
• [x] CCCSPSFSC+f, role ProxyChannel: is OK because data flows are not yet linked to indirect channels.
• [x] CCCCAP+ch, role ProxyChannel: is OK because attack paths are not yet linked to indirect channels.

The first of these is a bug, whereby the pattern can't be triggered when in principle it should be triggered by an AuthChannel. The next two are also bugs, but in the current domain model the relevant role could only be matched by a ClientChannel. The other cases could only be matched by a ClientChannel at that point in the construction sequence. Only the first must be fixed, but since the construction sequence may change in future, it would be best if the others were also updated so the role could be matched by any AuthChannel.

In threat patterns, almost all roles previously filled by a ClientChannel should now be broadened to include AuthChannels. In most cases the role is currently only filled by ClientChannels because of other features of the domain model (including how channels are constructed) but the roles should still be made broader so they are future proofed against possible changes elsewhere.

[mike1813]

This could affect access to data via an interactive process accessed remotely. It makes sense to fix it in branch 107 as a prerequisite for addressing #107.

[mike1813]

Addressed in branch 40.