Thumbprint L2 Construct for use with IAM OIDC Provider

[douglasnaphas]

Description

There is an L2 Construct for an OIDC Provider.

It uses a Custom Resource to (1) fetch the server thumbprint from the identity provider (IdP) from the IdP's X.509 Certificate, while doing some validation on the Certificate, if no thumbprint is provided, and (2) create/update/delete the OIDC Provider resource using SDK calls.

Since there is now a Cfn resource for an OIDC Provider, this proposal is to break out the logic for fetching the thumbprint into a new Thumbprint L2 Construct, separate from the OIDC Provider.

The Thumbprint would consist of a Custom Resource with much of the same logic currently in the OIDC Provider L2 Construct.

The intent would be for applications to use the Thumbprint to validate the IdP's X.509 Certificate and fetch the thumbprint, and to use the OIDC Provider Cfn resource to instantiate the OIDC Provider. Alternatively, applications could use the Thumbprint Construct as just described, but use an updated feature-flagged version of the OIDC Provider L2 Construct that accepts a Thumbprint as a prop.

This relates to aws/aws-cdk#21197, a request for the OIDC Provider L2 Construct to use the OIDC Provider Cfn resource.

Roles

Role	User
Proposed by	@douglasnaphas
Author(s)	@alias, @alias, @alias
API Bar Raiser	@alias
Stakeholders	@alias, @alias, @alias

See RFC Process for details

Workflow

• Tracking issue created (label: status/proposed)
• API bar raiser assigned (ping us at #aws-cdk-rfcs if needed)
• Kick off meeting
• RFC pull request submitted (label: status/review)
• Community reach out (via Slack and/or Twitter)
• API signed-off (label api-approved applied to pull request)
• Final comments period (label: status/final-comments-period)
• Approved and merged (label: status/approved)
• Execution plan submitted (label: status/planning)
• Plan approved and merged (label: status/implementing)
• Implementation complete (label: status/done)

---

Author is responsible to progress the RFC according to this checklist, and
apply the relevant labels to this issue so that the RFC table in README gets
updated.

[hassaku63]

I have implemented the approach mentioned in this issue as the Thumbprint construct.

https://github.com/hassaku63/cdk-oidc-provider-thumbprint-construct

Does this implementation meet the ideas of the RFC?

I am somewhat skeptical about the idea of expressing "Thumbprint" as a standalone CDK Construct.
What issues arise if we make it so that the thumbprint is directly obtained in the new version of the OIDCProvider L2 Construct (rather than through Thumbprint construct)? For example would there be problems with jsii compatibility?

[douglasnaphas]

@hassaku63 I’ll take a look at your implementation. Would love to get thoughts from any CDK maintainers on whether Thumbprint is a good idea.

[hassaku63]

@douglasnaphas Thank you for your comment. yeah me too. I'd like to hear others thoughts.

I have started working on the implementation to resolve this issue.

I am also considering other necessary changes such as Feature Flags. Once the design for the Thumbprint is decided, I plan to propose my implementation to the CDK repository, provided everything goes as expected.

[awsmjs]

Closing this ticket. We believe the functionality is beneficial, but does not intersect with the core framework and should be vended and maintained separately.