Skip to content

[KEYCLOAK-18723] - Configurable constraints for request object encryption#8261

Merged
mposolda merged 1 commit into
keycloak:masterfrom
pedroigor:KEYCLOAK-18723
Jul 20, 2021
Merged

[KEYCLOAK-18723] - Configurable constraints for request object encryption#8261
mposolda merged 1 commit into
keycloak:masterfrom
pedroigor:KEYCLOAK-18723

Conversation

@pedroigor

Copy link
Copy Markdown
Contributor

No description provided.

@pedroigor pedroigor added area/oidc Indicates an issue on OIDC area kind/enhancement Categorizes a PR related to an enhancement labels Jul 13, 2021
@pedroigor
pedroigor requested a review from mposolda July 13, 2021 12:26
@pedroigor

Copy link
Copy Markdown
Contributor Author

@tnorimat Could you check if it makes sense for you?

@tnorimat

Copy link
Copy Markdown
Contributor

@tnorimat tnorimat left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@pedroigor I have a few comments.

  • Request object encryption's "alg" and "enc"
    Unlike ID token encryption, It seems that only "alg" can be specified by client's setting(request_object_encryption_alg). How about supporting "enc" setting(request_object_encryption_enc)?

  • Server Metadata
    It might be better to add server metadata "request_object_encryption_alg_values_supported". As mentioned just above, if "enc" setting(request_object_encryption_enc) is supported, it might be better to add also "request_object_encryption_enc_values_supported".

@pedroigor

Copy link
Copy Markdown
Contributor Author

@pedroigor I have a few comments.

  • Request object encryption's "alg" and "enc"
    Unlike ID token encryption, It seems that only "alg" can be specified by client's setting(request_object_encryption_alg). How about supporting "enc" setting(request_object_encryption_enc)?

Makes sense. I can update this.

  • Server Metadata
    It might be better to add server metadata "request_object_encryption_alg_values_supported". As mentioned just above, if "enc" setting(request_object_encryption_enc) is supported, it might be better to add also "request_object_encryption_enc_values_supported".

Both are already supported as per #8243. See

config.setRequestObjectEncryptionAlgValuesSupported(getSupportedEncryptionAlgorithms());
.

@tnorimat

Copy link
Copy Markdown
Contributor

@pedroigor Yes, I forgot it.

@mposolda mposolda left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 for the Takashi's concern about alg and enc .

Also I've added one inline comment.

Finally, There is this condition in both FAPI and OpenBanking Brasil FAPI about the restrictions for the used alg and enc :
https://openid.net/specs/openid-financial-api-part-2-1_0.html#encryption-algorithm-considerations
https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-financial-api-1_ID1.html#section-6.1.1

I think that it will be nice to have executor (similar to SecureSigningAlgorithmExecutor), which will enforce this for new clients and check the algorithms for the existing clients. But that is probably something to consider in separate PR?

}

Boolean encryptionRequired = Optional.ofNullable(configuration.isEncryptionRequired()).orElse(Boolean.FALSE);
if (encryptionRequired && session.getAttribute(AuthzEndpointRequestParser.AUTHZ_REQUEST_OBJECT_ENCRYPTED) == null) {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@pedroigor It seems to me that with this flag encryptionRequired set to true, all clients in the realm (which will pass the client policy conditions) will be required to use encrypted request objects. Which I am not sure if it is desired behaviour.

IMO it will be good to stick with the same like for request object signatures. Which means that it would be enforced per the client if request object is encrypted just in case that request.object.encryption.alg is used for particular client. And this is already done in this PR (in AuthzEndpointRequestObjectParser).

In shortcut, my vote is to remove flag encryptionRequired from SecureRequestObjectExecutor. WDYT?

@pedroigor pedroigor Jul 19, 2021

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As you mentioned, clients that match the policy conditions.

I've opened a discussion on keycloak-dev about this topic in order to understand whether a setting should be at the client or at the client policy.

I agree with @tnorimat that moving configuration to policies is the best to do. And whether encryption is required looks like a good example.

As per signature, I guess it was done before client policies support. Right?

I'm not sure, for me either way works. Let me know if the above makes sense if not I can change to do the same as signature.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, we discussed this already some time ago during work on client policies and during designing client policies. And I also agree that it will be nice to move many of client switches and keep them at the client policy level. This will allow some flexibility (EG. enforce secure ID Token signature algorithm just in case that scope=fapi is requested, which is possible due the fact that client policy condition will be evaluated just with the scope=fapi and the particular executor for enforce algorithm will be also called just at that time etc).

However one thing is, that some configurations are enforced by OIDC specification itself at the client level (like the request_object_encryption_alg and request_object_encryption_enc) and hence for those switches we need to stick them at the client level exactly as you did in this PR.

I am personally still not sure if the particular switch encryptionRequired is needed on the executor as we don't have similar thing for the signature, but I don't see this as a blocker in this PR as it is false by default anyway. so I am approving this. Thanks for the updates!

@pedroigor
pedroigor force-pushed the KEYCLOAK-18723 branch 3 times, most recently from 89c9587 to 1734c8a Compare July 19, 2021 18:44
@pedroigor

Copy link
Copy Markdown
Contributor Author

@tnorimat Added support for content encryption settings.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

According to https://openid.net/specs/openid-connect-registration-1_0.html#ClientMetadata, it might be better to be

public static final String REQUEST_OBJECT_ENCRYPTION_ENC = "request.object.encryption.enc";

WDYT?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If https://github.com/keycloak/keycloak/pull/8261/files#r672633565 is agreed, it might be better to be getRequestObjectEncryptionEnc .

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If https://github.com/keycloak/keycloak/pull/8261/files#r672633565 is agreed, it might be better to be setRequestObjectEncryptionEnc .

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If https://github.com/keycloak/keycloak/pull/8261/files#r672633565 is agreed, it might be better to be 'request.object.encryption.enc.alg' .

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also to be requestObjectEncryptionEnc

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If https://github.com/keycloak/keycloak/pull/8261/files#r672633565 is agreed, it might be better to be changeRequestObjectEncryptionEnc .

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If https://github.com/keycloak/keycloak/pull/8261/files#r672633565 is agreed, it might be better to be 'request.object.encryption.enc' .

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The same just above.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If https://github.com/keycloak/keycloak/pull/8261/files#r672633565 is agreed, it might be better to be

<label class="col-md-2 control-label" for="requestObjectEncryptionEnc">{{:: 'request-object-encryption-enc' | translate}}</label>

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If https://github.com/keycloak/keycloak/pull/8261/files#r672633565 is agreed, it might be better to be

<select class="form-control" id="requestObjectEncryptionEnc"
    ng-change="changeRequestObjectEncryptionEnc()"
     ng-model="requestObjectEncryptionEnc">

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If https://github.com/keycloak/keycloak/pull/8261/files#r672633565 is agreed, it might be better to be 'request-object-encryption-enc.tooltip'

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The same just above.

@pedroigor

Copy link
Copy Markdown
Contributor Author

@tnorimat The name works for me too. Changed.

@tnorimat tnorimat left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@pedroigor I've confirmed your changes. Thank you.

@mposolda
mposolda merged commit 396a78b into keycloak:master Jul 20, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area/oidc Indicates an issue on OIDC area kind/enhancement Categorizes a PR related to an enhancement

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants