microsoft / spid-and-digital-identity-enabler Goto Github PK

We need to add pipelines which can be used as checks for PRs. Such pipelines should at least build the CNS and SPIDProxy project. Eventually, when added, should run Unit Tests.

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.

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.

The certificate StoreLocation is hardcoded to CurrentUser, hence not configurable. This is fine on Azure App Service but could lead to problems on IIS especially when using AppPoolIdentity.

We need to update the custom policies for CIE because the dateOfBirth claim is returned as string instead of date

Buonasera, sono sempre io,
ho dei problemi con l'integrazione di CNS, in sostanza nel trustframeworkExtension devo inserire nei setting il valore:
"CNSSAMLMetadata": "The metadata url for the CNS middleware. Used only if you want to use CNS"

questo valore è relativo alla webapp dove è situato il CNS

nella descrizione dell'installer la guida fa questo:

CNSSAMLMetadata si utilizza solo nel caso in cui si vuole abilitare il meccanismo di autenticazione tramite CNS. Nello specifico bisognerà inserire l'url statico dell'applicazione web contente i metadata necessari.

quindi ho preso ed ho messo la url di riferimento: https://nomebebapp.azurewebsites.net/cns/index

inserendo questa però vado in 403 - unahautorized

dietro a questo errore andando ad indagare c'è questo problema:

IN LOCALE HO QUESTO ERRORE:

eppure ho installato correttamente sia la card che la tessera sanitaria, mi viene letto il certificato all'interno del CNS, il punto è che il thumbprint che mi viene letto non è quello segnato in configurazione (f661b62b33233ab68b51aa1fa85ba18507ba634a) ma è questo: 57B2B9B20BB515639694819975D749B21754D9CD

SULLA WEBAPP PUBBLICATA:
ho l'errore medesimo ma perchè la lista: certStore.Certificates è vuota, sembra non leggermi nemmeno la scheda.

dove sta l'errore nella configurazione? anche perchè se per testare tolgo l'autorizzazione va comunque in errore il Middleware.

se mi date supporto così come nell'altra issue, dove ho inserito la soluzione, posso mettere una miniguida leggermente più specifica per risolvere questo eventuale errore.

Grazie del supporto

I am opening this issue for a problem regarding the retrieval of some URLs. I followed several official and unofficial documentations in an attempt to find the B2C metadata URL as a service provider, but I only found metadata for identity provider.

According to this documentation: https://learn.microsoft.com/en-us/azure/active-directory-b2c/saml-service-provider?tabs=windows&pivots=b2c-custom-policy, the metadata URL should be exposed in the manifest through this value: "samlMetadataUrl":"https://mytestapp.azurewebsites.net/Metadata". I tried several times without being able to reach the correct URL. Other documentations indicated that the correct metadata can be found on this page:

https://tenant-name.b2clogin.com/tenant-name.onmicrosoft.com/policy-name/samlp/metadata

But even this link seems to lead nowhere. We only found one working URL that actually contains SAML metadata, which corresponds to the following:

https://tenant-name.b2clogin.com/tenant-name.onmicrosoft.com/policy-name/samlp/metadata?idptp=technical-profile-name

However, this URL is not usable for authentication in the SPID validator demo because it lacks many values such as the organization, and therefore is not validated correctly. Additionally, this URL by analogy should contain the IdP metadata and be defined as "Azure AD B2C IdP SAML metadata" and therefore is not correct to be used as a service provider.

Where can I find the correct URL to retrieve the metadata to send to AgID?

Apro questa issue per un problema riguardo al reperimento di alcune url, ho seguito diverse documentazioni ufficiali e non nel tentativo di trovare la url dei matadati di B2C come service provider, tuttavia ho trovato solamente i metadati per identity provider.

seguendo questa documentazione: https://learn.microsoft.com/en-us/azure/active-directory-b2c/saml-service-provider?tabs=windows&pivots=b2c-custom-policy
La url dei metadati dovrebbe essere esposta nel manifest tramite questo valore:
"samlMetadataUrl":"https://mytestapp.azurewebsites.net/Metadata",
ho fatto diversi tentativi senza riuscire a raggiungere la url coretta
altre documentazioni segnavano come corretti i metadati della pagina

https://tenant-name.b2clogin.com/tenant-name.onmicrosoft.com/policy-name/samlp/metadata

ma effettivamente anche questo link sembra non portare a nulla. Abbiamo trovato solamente una url funzionante che contiene effettivamente dei metadata SAML che corrisponde alla seguente:

https://tenant-name.b2clogin.com/tenant-name.onmicrosoft.com/policy-name/samlp/metadata?idptp=tecnical-profile-name
ma questa url non è utilizzabile per l’autenticazione nella demo del validator dello spid perché manca di molti valori quali, ad esempio l’organization e quindi non viene validata correttamente.
Inoltre questa url per similitudine dovrebbe contenere i metadati da IdP ed essere quella definita come “Azure AD B2C IdP SAML metadata” ed quindi non è corretta per essere utilizzata come service provider.

dove posso trovare la url corretta per ritirare i metadati da inviare ad Agid?

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 ?

For some reasone the /p:version MsBuild argument is not working as expected. Published dlls don't have the right version

Some organizations want the SAMLResponse received from the IdPs to be logged also in a decoded format. We can add an option to do so (default to false)

Now CIE supports also SpidLevel1 and 2, so we need a way to manage the default SpidLevel for SPID and CIE separately.

From my tests, for CIE:

• comparison exact + a specific SpidLevel, forces the user to use that level
• comparison minimum + any SpidLevel means SpidLevel3, hence the user must authenticate with the smart card phisically.

As of today, for CIE, the SpidProxy always send a SamlRequest with comparison minimum and the configured spidlevel.

SpidLevel 1 and 2 credentials for CIE must be activated by the user first.

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

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

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.

la procedura di log in dell'ambiente di test di CIE non va a buon fine, prima della redirect finale B2C va in errore:

premetto che lo spid proxy ha le configurazioni apparentemente settate correttamente, dopo che nel browser appare la pagina

• SPIDProxy is redirecting you... - quindi, dopo la pagina di redirect dell'AssertionConsumer b2c va in errore dicendomi:

quindi dentro l'eccezione trovo questo ripetuto tre volte:
"Key": "Exception",
"Value": {
"Kind": "Handled",
"HResult": "80131500",
"Message": "The service provider is not a valid audience of the assertion.",
"Data": {
"IsPolicySpecificError": false
}

premesso che l'ambiente di SPID funziona correttamente e che ho portato a compimento tutto il processo di autenticazione per il collaudo, questo errore dovrebbe essere dovuto ad una discrepanza tra l'EntityID nei vari punti dove viene inserito, tra metadati e configurazioni, e l'audience, che mi arriva nella SAMLresponse, tuttavia questa discrepanza non c'è, funziona tutto correttamente, le redirect sono quelle corrette, il CIE_EntityID è corretto e risulta essere lo stesso sia nel portale CIE sia nei metadata inseriti nel portale CIE sia nelle configurazioni della webapp.

Manca qualcosa a me o c'è un qualche bug?

non so se sia rilevante ma nel TrustFrameworkExtension i valori di cie e cie-test sono invertiti, a riga 573 e 585 hanno i valori invertiti rispetto al TecnicalProfile di riferimento. sono io che non ho capito qualcosa o sono effettivamente invertiti?

Grazie mille in anticipo,
Giovanni

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:

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

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

The release.zip available under Releases is not ready for deployment since it has subfolders. We should fix the GitHub Action worklow to have no subfolders in the zip file.

Having the release.zip file without subfolders is extremely useful for Zip Push Deploy on Azure App Service.

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.

Can be useful add some unit tests to the projects.

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.

If the signing certificate is non self-signed, a System.Security.Cryptography.CryptographicException is thrown with the following message: A certificate chain could not be built to a trusted root authority.

This happens because of the following line whenever the root ca and the intermediate ca are not installed on the machine, which is usually the case on Azure App Service. Changing the X509IncludeOption to EndCertOnly fixes the issue and should work in any case, since self-signed cert don't have a chain at all and signatures generated with non self-signed cert don't require the whole chain in the signature KeyInfo.

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

I think that can be a good improvement execute porting of Project CNS.Auth.Web from .NET 5 to .NET 6

Hi, thanks for your good work!

I have an AAD (now entraID) tenant without on-premises connection and I am trying to understand: is there any scenario in which one can have spid users log in to AAD as guests by using their SPID identity and leveraging this proxy?

Thanks!

We should validate the SAMLRequest signature incoming from the Federator to have an additional layer of security

The CNS proj doesn't have a pipeline to build and create a release.