Requests to /cloudfoundryapplication possibly return results for /actuator

[TimHess]

Describe the bug

In CF context, only /health and /info are reported as being enabled

Sample response:

{
    "type": "steeltoe",
    "_links": {
        "info": {
            "href": "https://steeltoe-samples-server.apps.dhaka.cf-app.com/cloudfoundryapplication/info",
            "templated": false
        },
        "health": {
            "href": "https://steeltoe-samples-server.apps.dhaka.cf-app.com/cloudfoundryapplication/health",
            "templated": false
        },
        "self": {
            "href": "https://steeltoe-samples-server.apps.dhaka.cf-app.com/cloudfoundryapplication",
            "templated": false
        }
    }
}

Steps to reproduce

Steps to reproduce the behavior:

1. Add Actuators to app
2. Deploy to CF
3. View app in apps manager

Expected behavior

All endpoints supported on Cloud Foundry should be returned/enabled automatically

Environment (please complete the following information):

• Steeltoe Version main
• Platform: Cloud Foundry
• OS: Linux
• .NET Version 8.0

[TimHess]

Probably related:

2024-05-29T13:57:16.458-05:00 [APP/PROC/WEB/0] [OUT] IDX10242: Security token: '[Security Artifact of type 'Microsoft.IdentityModel.JsonWebTokens.JsonWebToken' is hidden. For more details, see https://aka.ms/IdentityModel/SecurityArtifactLogging.]' has a valid signature.
2024-05-29T13:57:16.459-05:00 [APP/PROC/WEB/0] [OUT] IDX10239: Lifetime of the token is valid.
2024-05-29T13:57:16.459-05:00 [APP/PROC/WEB/0] [OUT] IDX10214: Audience validation failed. Audiences: 'cloud_controller, actuator, apps_manager_js'. Did not match: validationParameters.ValidAudience: 'null' or validationParameters.ValidAudiences: 'sampleapi, 4e6f8e34-f42b-440e-a042-f2b13c1d5bed'.
2024-05-29T13:57:16.459-05:00 [APP/PROC/WEB/0] [OUT] info: Microsoft.AspNetCore.Authentication.JwtBearer.JwtBearerHandler[1]
2024-05-29T13:57:16.459-05:00 [APP/PROC/WEB/0] [OUT] Failed to validate the token.
2024-05-29T13:57:16.459-05:00 [APP/PROC/WEB/0] [OUT] Microsoft.IdentityModel.Tokens.SecurityTokenInvalidAudienceException: IDX10214: Audience validation failed. Audiences: 'cloud_controller, actuator, apps_manager_js'. Did not match: validationParameters.ValidAudience: 'null' or validationParameters.ValidAudiences: 'sampleapi, 4e6f8e34-f42b-440e-a042-f2b13c1d5bed'.
2024-05-29T13:57:16.459-05:00 [APP/PROC/WEB/0] [OUT] at Microsoft.IdentityModel.Tokens.Validators.ValidateAudience(IEnumerable`1 audiences, SecurityToken securityToken, TokenValidationParameters validationParameters)
2024-05-29T13:57:16.459-05:00 [APP/PROC/WEB/0] [OUT] at Microsoft.IdentityModel.JsonWebTokens.JsonWebTokenHandler.ValidateTokenPayloadAsync(JsonWebToken jsonWebToken, TokenValidationParameters validationParameters, BaseConfiguration configuration)
2024-05-29T13:57:16.459-05:00 [APP/PROC/WEB/0] [OUT] at Microsoft.IdentityModel.JsonWebTokens.JsonWebTokenHandler.ValidateJWSAsync(JsonWebToken jsonWebToken, TokenValidationParameters validationParameters, BaseConfiguration configuration)
2024-05-29T13:57:16.459-05:00 [APP/PROC/WEB/0] [OUT] info: Microsoft.AspNetCore.Authentication.JwtBearer.JwtBearerHandler[7]

[bart-vmware]

While looking into this, we should take the following Sonar security hotspot into account:

The proposal is to replace the wildcard with the hostname obtained from VCAP_APPLICATION. If unavailable, Steeltoe shouldn't set the wildcard policy.

Once implemented, #959 can be closed.

[bart-vmware]

Once this is implemented, the test at src/Management/test/Endpoint.Test/ActuatorsHostBuilderTest.cs should be updated as described at #1386 (comment).

[TimHess]

Probably related:

2024-05-29T13:57:16.458-05:00 [APP/PROC/WEB/0] [OUT] IDX10242: Security token: '[Security Artifact of type 'Microsoft.IdentityModel.JsonWebTokens.JsonWebToken' is hidden. For more details, see https://aka.ms/IdentityModel/SecurityArtifactLogging.]' has a valid signature.
2024-05-29T13:57:16.459-05:00 [APP/PROC/WEB/0] [OUT] IDX10239: Lifetime of the token is valid.
2024-05-29T13:57:16.459-05:00 [APP/PROC/WEB/0] [OUT] IDX10214: Audience validation failed. Audiences: 'cloud_controller, actuator, apps_manager_js'. Did not match: validationParameters.ValidAudience: 'null' or validationParameters.ValidAudiences: 'sampleapi, 4e6f8e34-f42b-440e-a042-f2b13c1d5bed'.
2024-05-29T13:57:16.459-05:00 [APP/PROC/WEB/0] [OUT] info: Microsoft.AspNetCore.Authentication.JwtBearer.JwtBearerHandler[1]
2024-05-29T13:57:16.459-05:00 [APP/PROC/WEB/0] [OUT] Failed to validate the token.
2024-05-29T13:57:16.459-05:00 [APP/PROC/WEB/0] [OUT] Microsoft.IdentityModel.Tokens.SecurityTokenInvalidAudienceException: IDX10214: Audience validation failed. Audiences: 'cloud_controller, actuator, apps_manager_js'. Did not match: validationParameters.ValidAudience: 'null' or validationParameters.ValidAudiences: 'sampleapi, 4e6f8e34-f42b-440e-a042-f2b13c1d5bed'.
2024-05-29T13:57:16.459-05:00 [APP/PROC/WEB/0] [OUT] at Microsoft.IdentityModel.Tokens.Validators.ValidateAudience(IEnumerable`1 audiences, SecurityToken securityToken, TokenValidationParameters validationParameters)
2024-05-29T13:57:16.459-05:00 [APP/PROC/WEB/0] [OUT] at Microsoft.IdentityModel.JsonWebTokens.JsonWebTokenHandler.ValidateTokenPayloadAsync(JsonWebToken jsonWebToken, TokenValidationParameters validationParameters, BaseConfiguration configuration)
2024-05-29T13:57:16.459-05:00 [APP/PROC/WEB/0] [OUT] at Microsoft.IdentityModel.JsonWebTokens.JsonWebTokenHandler.ValidateJWSAsync(JsonWebToken jsonWebToken, TokenValidationParameters validationParameters, BaseConfiguration configuration)
2024-05-29T13:57:16.459-05:00 [APP/PROC/WEB/0] [OUT] info: Microsoft.AspNetCore.Authentication.JwtBearer.JwtBearerHandler[7]

I'm not seeing evidence this was actually related. There was no special handling present for /cloudfoundryapplication in the current version of the exposure logic for actuator endpoints. In retrospect, I think these log entries were more likely due to something specific to that sample application

[TimHess]

While looking into this, we should take the following Sonar security hotspot into account:

The proposal is to replace the wildcard with the hostname obtained from VCAP_APPLICATION. If unavailable, Steeltoe shouldn't set the wildcard policy.

Once implemented, #959 can be closed.

I looked at this again this morning, but I don't think there's a way to do this. The URIs provided by VCAP_APPLICATION will match app-route.apps-domain, but Apps Manager will be running under apps.system-domain, where (I think) apps-domain and system-domain can't match exactly... Even in cases (like our test environments) where they are close, we'd need to backtrack from the full route to a guess at what apps-domain probably is, and guess at where apps manager lives. We're better off improving the documentation for how to do this precisely.