search

keycloak / kc-sig-fapi

Apache License 2.0
70 stars 51 forks source link

Resource Server related FAILURE : OB-6.2.1-2 #9

Closed tnorimat closed 4 years ago

tnorimat commented 5 years ago

CallAccountsEndpointWithBearerTokenExpectingError checks whether a resource server returns an error when a client 1 send an access token issued to a client 2. It checks a requirement of OpenBanking Security Profile section 6.2.1-2.

To pass these tests, the resource server defined as "resourceUrl" in the config file needs to be configured to satisfy a requirement of OpenBanking Security Profile section 6.2.1-2.

This requirement tells that the resource server with the FAPI endpoints shall verify that the client identifier bound to the underlying mutually authenticated TLS transport session matches the client that the access token was issued to. That means we shall use [MTLS] as client authentication, not private_key_jwt. Therefore, this check should be omitted for private_key_jwt testplan.

These test should be omitted because the test plan is for the authorization server (keycloak), not the resource server. And, this test is for OpenBanking Security Profile, not FAPI.

wadahiro commented 4 years ago

On fix-resource-server branch, I implemented the introspection and MTLS verification on the resource server temporarily by keycloak-gatekeeper customization in the following commit:

Then I tested fapi-rw-id2-ensure-request-object-with-multiple-aud-succeeds-with-private-key-and-mtls-holder-of-key again.

I confirmed CallAccountsEndpointWithBearerTokenExpectingError (OB-6.2.1-2) didn't passed in the test-case trying Client1 Crypto Keys with Client2 token:

image

But the other CallAccountsEndpointWithBearerTokenExpectingError (RFC6749-4.1.2) wasn't passed correctly due to WARN. The test-case attempts reuse of client2's authorization code & test if access token is revoked:

image

I checked RFC6749-4.1.2. It says:

         if an authorization code is used more than
         once, the authorization server MUST deny the request and SHOULD
         revoke (when possible) all tokens previously issued based on
         that authorization code.

Should we support the revocation in keycloak? Or it's implemented on the latest keycloak?

wadahiro commented 4 years ago

Sorry, the second case is described in #27. So this issue for OB-6.2.1-2 was fixed. Closing this ticket is ok.

tnorimat commented 4 years ago

@wadahiro I see, could you write the same comments on https://github.com/jsoss-sig/keycloak-fapi/issues/27 ?

wadahiro commented 4 years ago

@tnorimat yes, I wrote.

tnorimat commented 4 years ago

@wadahiro Thank you. I'll close this issue.