I've faced an issue trying to use certificates with a 3k key length. Problem faced were:

• SPID Proxy Web App unable to open certificate private key with error "certificate password incorrect"
• Azure AD B2C user flow unable to open certificate private key for SAML message signing

Opening the certificate with MMC or openSSL worked without issues and the password was correctly accepted.

Recreating the certificate with same settings, but 2048 key length resolved all the issues.

We actually generate the AssertionConsumerServiceUrl using the HTTP Request host. This won't work in scenarios where reverse proxies are used, since the request host will be different from the "public" host that users can reach.

We basically need to change the following line https://github.com/microsoft/SPID-and-Digital-Identity-Enabler/blob/63ef10fe45b82566d90d4fc0101f0a254603be5d/WebApps/Proxy/Microsoft.SPID.Proxy/Services/Implementations/SAMLService.cs#L32-L36

We could use the x-forwarded-host header (https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/proxy-load-balancer?view=aspnetcore-6.0) or, eventually, just put the right host in config.

The Get-SPIDMetadatas PS script use the following code to load the certificate: $cert = (New-Object System.IO.StreamReader($certificateFilePath)).ReadToEnd() This code considers that the certificate file contains the plain certificate in base64. Unfortunately usually .cer file format is defined as follow -----BEGIN CERTIFICATE----- <base64 certificate> -----END CERTIFICATE----- So, at current time, the PS script generates the XML metadata as follows <md:KeyDescriptor use="signing"> <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:X509Data> <ds:X509Certificate>-----BEGIN CERTIFICATE----- ..... -----END CERTIFICATE----- </ds:X509Certificate> This is a not valid certificate data inside the XML metadata

TL;DR;
I'm willing to reduce the logs sent to AppInsights changing the category filters. At the same time i would like to disable the AdaptiveSampling by default to avoid loosing important logs which are mandatory for AgID.

Details
With the actual default configuration, we send Information logs to AppInsights for every single category:

{
	"Logging": {
		"ApplicationInsights": {
			"LogLevel": {
				"Default": "Information"
			}
		}
       }
}

With this configuration we are also sending framework logs such as the following, which are not really useful and could produce a lot of data-ingestion

Should we change the category filters for AppInsights to send Information logs and above for the Microsoft.SPID cateogory and sending only Warning and above logs for the Default category? Something like this:

{
	"Logging": {
		"ApplicationInsights": {
			"LogLevel": {
				"Default": "Warning",
                                "Microsoft.SPID": "Information"
			}
		}
       }
}

We could increase the verbosity at any-time by overriding the setting via Configuration. I would like to reduce the telemetry sent to AppInsights because AgID requires to store logs for 24 months. We can change the retention of the Application Insights instance to achieve the objective (via the linked LAW or on the AppInsights instance directly), but it has an extra-cost per-GB/per-Month.

Moreover, we have Adaptive Sampling enabled by default. Whene there are a lot of concurrent requets towards the SPIDProxy, sampling is applied hence we loose log details but still have correct numbers (thanks to the itemCount). I would like to disable Sampling by default since we could sample a log which is required by AgID and which we should retain for 24 months. We can do so by adding the following in the appsettings.json, as also shown here https://docs.microsoft.com/en-us/azure/azure-monitor/app/asp-net-core#configuration-recommendation-for-microsoftapplicationinsightsaspnetcore-sdk-2150-and-later:

{
    "ApplicationInsights": {
        "EnableAdaptiveSampling": false
    }
}

What do you think @tommasodotNET, @MarcoZama, @PaoloCastAway ?

I create this installation steps, i write the readme that guides the user in this step:

• How to deploy the custom policies in AAD B2C
• How to deploy and configure the SPIDProxy
• How to get started with the demo.spid.gov.it environment

If the SAMLRequest destination is a CIE environment, then you can use a specific entityId via CIEEntityId setting. This is useful in the case you have different EntityId set in CIE and SPID metadatas.

As of today, if we have to use two different Issuers for SAMLRequests for CIE and SPID, we must deploy two parallel SPIDProxies. Would be great to have a configuration to achieve the same. I.e., whend sending SAMLReuqests to spid use spid.entity.id and when sending SAMLRequests to CIE use cie.entity.id. We already have a configuration to use different AttributeConsumingServiceIndex for SPID and CIE, so we could use the same approach.

cc: @mtagliaferri86

thanks @vifani for the main contribution.

Added optional KeyVault Configuration Provider support Added Certificate load switch from server file storage or KeyVault

SAMLRequest schema dictates to have the Extensions tag right after the Signature, hence we must add it after the Issuer tag.

The code to change is here: https://github.com/microsoft/SPID-and-Digital-Identity-Enabler/blob/ada2d5fc94686d23e882f0bc443ae8a534d45ce3/WebApps/Proxy/Microsoft.SPID.Proxy/Models/Extensions/RequestSAMLAsXMLExtensions.cs#L175

Instead of appending the Extensions to rootEl, we should InsertAfter the Issuer tag, which we should retrieve.

Having a flag to disable SAMLResponse signature validation entirely could be useful for testing pruposes. As of now, we have such a flag to skip Assertion signature validation only.

• Add LoggingOptions class with LogDecodedSamlResponse prop (defaults to false)
• Add SPIDProxyLogging section in appsettings.json
• Move LogAccess section inside SPIDProxyLogging section
• Change Configure methods accordingly
• Add INCOMING_SAML_RESPONSE_DECODED event

Fixes #9

While waiting for the deployment automation (#6), we should write the installation steps in the readme:

• How to deploy the custom policies in AAD B2C
• How to deploy and configure the SPIDProxy
• How to get started with the demo.spid.gov.it environment

When we install the SPIDProxy, we must configure the "Federator" section manually with appropriate EntityIDs and appropriate AttributeConsumerServiceUrl. Such informations could be retrieved from the Federator metadata and from the metadata shared with AgID. We could add the chance to just configure metadatas urls and retrieve such informations on the fly on startup.

Reading from Cert Store is a better option even when SPIDProxy is deployed in Azure. Cert is stored in KeyVault, then imported into App Service (see Import a certificate from your vault to your app). The good thing is that you update the Cert in KeyVault, and then it's automatically imported into App Service.

You need just to declare in Configuration the Tumbprint of certificates to be made available to code. Then, you use the approach described here (Use a TLS/SSL certificate in your code in App Service): this approach doesn't make any assumption code is running in Azure, so it satisfies the requirement.