Affects Version/s: 6.5.1
Component/s: OAuth 2.0
Sprint:2019.8 - IG / Microservices, 2019.9 - IG / Microservices, 2019.10 - IG / Microservices, 2019.11 - IG / Microservices, 2019.13 - IG / Microservices, 2019.14 - IG / Microservices, 2019.15 - IG / Microservices, 2019.16 - IG / Microservices
This issue affects IG when configured as a resource server validating access tokens via mTLS, as per
Currently, Tomcat needs to be configured for TLS client authentication, and IG reads the TLS client certificate in use from the Tomcat context.
This presents an issue where the IG Tomcat instance is not the TLS termination point - e.g. if IG is behind a load balancer or other ingress point (e.g. a typical k8s deployment). In this case, the only way to get the client certificate to the IG container is via an HTTP header injected by the ingress point.
We should follow the model used by AM in its corresponding mTLS configuration, where the client certificate can either be read directly from the Tomcat context, or via a named HTTP header.
- ConfirmationKey ATR can be configured to read thumbprint (not just certificate) from context/request
- Introduce new API
- Supported options:
- As of today: read from ClientContext and compute the hash
- read from PEM encoded certificate passed in header, compute the hash
- read the hash from header directly
- script for obtaining a thumbprint given the context, request pair