Current plugin does not support Azure AD authentication

[caleteeter]

The current plugin has some incompatibilities with Azure AD authentication.

1. The audience value cannot be set to the format in the current plugin for AAD (Node1,Node2). The reason is the audience value for the token from AAD using an application id uri scheme. (e.g. api://qrm) to uniquely identify the application (and token).

2. The scope format used the current plugin has 2 incompatibilities.
   a) The application uri scheme will preface each custom scope (e.g. api://qrm/)
   b) The token format for the scopes is space delimited, not a string array.

I have a fork, working on the changes and will PR them.

[trung]

@caleteeter

Thanks for the suggestion. Few feedbacks as below:

1. One of the token verification steps is to verify aud in the token with the node identity. This enforces the access control of an application to authorized nodes. If aud represents application id, can you elaborate how it can be used to verify the token?

2.a. Can you elaborate this a bit more?

2.b. Indeed, scope value can be an array. Documentation needs to be updated to reflect this.
https://github.com/ConsenSys/quorum-security-plugin-enterprise/blob/e52db3c2f7a19ecce8eff6ba039c20e836212edc/internal/oauth2/jwt.go#L90-L10

[caleteeter]

On the first item here about validating the aud with the node identity, it makes sense what is there today. In the case of AAD, because its an full identity service, the audience value is the "application" that represents the actual application that is deployed. (details). With AAD, the client should validate the application id based on application configuration with the token received.

On 2a, to elaborate. The token generated by AAD will preface each scope with the application id uri (the id that represents this unique application registration (format: api://).

On 2b, good deal, I will test this.

[trung]

1 ) I see, so the responsibility is with the client to verify the aud value and not with the resource server. Maybe a flag in the config to opt out aud check would be enough.

2b) Got it. The current scope is also of URI format (e.g.: rpc://eth_sendTransaction). Maybe we need to have different parsers for different scope format

[benjamincburns]

@trung unfortunately opting out of the aud check introduces a security vulnerability, as otherwise valid tokens that were issued for some other audience can be used to gain access. That is, an attacker can set up their own Azure AD application, grab a token for that one, and then use it to access the node. Admittedly the role ids likely wouldn't match, so they wouldn't be authorized to actually do anything, but all the same, solutions that don't check the aud claim won't pass security audits.

[trung]

aud can be application ID or resource URI. Per documentation, Azure AD v1.0 supports resource URI and v2.0 supports both.
The concern is with implicit grant flow. @caleteeter, with Azure AD, wondering how a resource server authenticates clients without checking aud? It doesn't seem right to me if a resource server needs to know about application IDs

[benjamincburns]

@trung I'm obviously not @caleteeter, but I'm weighing in to keep things moving along... It seems logical that in cases when the resource server is a policy enforcement point (as quorum is in this case), it would need to know its own application id. Otherwise how does it know that the inputs for the policies that its enforcing are valid in the context of its own application scope?

[caleteeter]

Sorry for the lag here, got a few plates spinning. I did discuss this case with someone on the AAD team. Here is what I was thinking.

The aud value will be a URI: api://. I was thinking that this will be present in the access token presented to the plugin and the plugin is preconfigured with the check for the correct audience. In this case Quorum is the client validating this audience. This looks similar to the hydra setup, where the access token requested by the user, include the audience. In our case this in the URI.

Would that not suffice?