Ambiente di test ed integrazione CIE - Keycloak - OIDC

CIE
87

Ciao @glauco ottengo anche io "“Non è possibile procedere. La sessione non è piu’ valida. E’ necessario eseguire una nuova autenticazione.”
Oltretutto se provo a chiamare endpoint di fetch o resolve mi risponde "{“error”: “temporarily_unavailable”, “error_description”: “Non è stato possibile recuperare l’entity configuration”}.
Il mio EC è disponibile qui https://cie-qas.progettiesoluzioni.it/.well-known/openid-federation?output=json
mentre pagina di login al momento la sto utilizzando da locale quindi non potrei fornirtela.
Sai se altri hanno risolto il problema di quel messaggio sulla sessione non valida?
Grazie

88

Buongiorno Francesco,
sto diventando pazzo a mettere su un ambiente di test per un applicazione con la libreria spid-ce-oidc-aspnetcore,
che configurazioni hai messo su docker per farlo dialogare con localhost?
grazie
Paolo

89

Ma all’errore “L’applicazione a cui hai acceduto non è registrata per l’utilizzo con questo servizio.” qualcuno ha trovato una soluzione?

90

Capita per diversi motivi.

Assicuratevi di aver inserito l’entityID esattamente come l’avete messo nel portale di federazione e che sia presente dove necessario nelle richieste e token di accesso.

92

Io sul portale di federazione sono federato come aggregatore full, quindi l’autenticazione la faccio per un RP che dovrebbe federarsi in automatico

93

Ciao Andrea,
sto tentando anche io federarmi come soggetto aggregatore full nell’ambiente di preprod.
A beneficio anche per chi verrà dopo di me, sei riuscito a risolvere il problema di registrazione automatica dei tuoi RP subordinates? Sai darmi qualche dritta in merito?
Grazie

94

Sì ci sono riuscito, anche col supporto di IPZS. Che errore ti ritorna?

95

In realtà siamo ancora bloccati all’errore di SUB mancante, nonostante inviamo le nostre keys con questo formato:

{
  "keys": [
    {
      "alg": "RS256",
      "kid": "2DHdzTMF08Dle_ffhAo1vCIWPK0qGa-nBmeSrRmBG-g",
      "kty": "RSA",
      "n": "rc9Fn03uMpWTVf49t2KujxdpsAhNYyg_xQyGSanz_iNQOh42t0dUySmVhUSUtSERgetpH4kEh6_rnGKssWXJtk-oH8wyjwGYLheXu6rEq3jitQQx0A-q9XiD1duxi83s5fLiBSd1MpYvUmTKcreDo1aNyH0C9aTFdvQU7YbtVMMv9SPwsM3buI8x2y9THWCjZwpnbakIgTqTtHHrHRD0qTU-ln98aUA-uxhD3Tux5Yu7d7c5DogzWmhqhJhmoEZXkiI-omPoUdJuU822oC_1bKftjQWv1UGZARIRVPufmEV7BjA4CdUbvgXNE4CwQ-BDv607vze5yfyaQtkqPuE_5Q",
      "e": "AQAB",
      "use": "sig"
    }
  ]
}

Speravamo di risolvere aggiustando alcune cose nel .well-known, e quindi mi sono portato avanti su quello che sapevo sarebbe stato il prossimo problema, ma a quanto pare ho peccato di presunzione.
Nel dubbio lo potete consultare qui, magari trovate qualche problema che noi non notiamo: https://cie.collaudo.sourcesense.com/realms/cie-coll-sa/oidcfed/.well-known/openid-federation?format=json
@IPZS-CIE
Grazie

96

Credo che il problema sia che la chiave che state cercando di aggiungere alla federazione non è indicata nel vostro openid-federation come una chiave di federazione, ma come chiave di firma dei metadata.

In altre parole, la chiave che usate per firmare le richieste verso l’ID server CIE deve figurare all’attributo metadata.openid_relying_party.jwks.keys, che è poi quella che inserite nel portale.

Fatemi sapere se questo risolve il problema.

97

Ciao Francesco,
intanto grazie mille per la risposta.
Noi però dobbiamo federarci come soggetto aggregatore, e nel well-known dello stesso non dobbiamo avere una sezione metadata.openid_relying_party, in quanto appunto è riservata ai relying party.
Ci siamo anche confrontati con altri well-known di SA di cui si parlava in questo thread, i quali sono riusciti con successo a federarsi (vedasi presenza del trust_mark), ad esempio: https://cie-qas.progettiesoluzioni.it/.well-known/openid-federation?output=json
Ci sfugge qualcosa?

1 Mi Piace
98

Cerca di rispettare la stressa struttura del mio EC che vedi all’indirizzo che conosci già (es. togli trust_mark_issuer, inserisci trust_marks= [], etc.).
Elimina dalle chiavi il certificato, quindi rimuovi x5c, x5t e x5t#S256.

Altra curiosità…come generi kid ed n? Spero utilizzando il certificato x509.

Comunque controlla anche la struttura del certificato, io la vedo scarna rispetto alla mia che puoi vedere decodificandolo, cerca di allinearla:

-----BEGIN CERTIFICATE-----

MIIEAzCCAusCFAyG0DzrTkRC66yZ65MZIK3yDDA0MA0GCSqGSIb3DQEBCwUAMIG9

MQswCQYDVQQGEwJJVDENMAsGA1UEBwwEQmFyaTEhMB8GA1UECgwYUHJvZ2V0dGkg

ZSBTb2x1emlvbmkgU3BBMS8wLQYDVQQDDCZodHRwczovL2NpZS1xYXMucHJvZ2V0

dGllc29sdXppb25pLml0LzEvMC0GA1UEUwwmaHR0cHM6Ly9jaWUtcWFzLnByb2dl

dHRpZXNvbHV6aW9uaS5pdC8xGjAYBgNVBGEMEVZBVElULTA2NDIzMjQwNzI3MB4X

DTI0MTIxODE1NTQ0OFoXDTM0MTIxNjE1NTQ0OFowgb0xCzAJBgNVBAYTAklUMQ0w

CwYDVQQHDARCYXJpMSEwHwYDVQQKDBhQcm9nZXR0aSBlIFNvbHV6aW9uaSBTcEEx

LzAtBgNVBAMMJmh0dHBzOi8vY2llLXFhcy5wcm9nZXR0aWVzb2x1emlvbmkuaXQv

MS8wLQYDVQRTDCZodHRwczovL2NpZS1xYXMucHJvZ2V0dGllc29sdXppb25pLml0

LzEaMBgGA1UEYQwRVkFUSVQtMDY0MjMyNDA3MjcwggEiMA0GCSqGSIb3DQEBAQUA

A4IBDwAwggEKAoIBAQCcUMMQVdtSwe4OCjnU17DXJBesMJVSgRcZ/F2H5xSSTQiK

8BSl1BBQ1MvH+oxAwvQaGZ6V7w62fuQxi6bNtlIGh2mjkirCaI4BW1kMW2XGoi+h

+Sfjzxk0BHI183N5PVlKCdkFXxSTnH9xZHfszOhGaxf8oIpIYhI+xKvT1FMyCjLm

UA4LIUcUdIyG+EjnQlQAsC2btyBE4Cv1paoCC9eOlsTdRrbboHXmIvC3HjVNMklg

vidnVXMtAVWrtF988IGGXHAJ8CWbdZfMt+gWM/jCcCBnCaOEz/48p6LpVfqvJiaK

hrvAX5ajhpbsfdx6h7N+6h/ErixuZ67fBYnxl5J7AgMBAAEwDQYJKoZIhvcNAQEL

BQADggEBAH3waW6ECFeOLR+DfV0NhJM+clSAnucSFoep+eR+KMgB4H5z6jYDufl4

bMkL5VqgEEKNck/g5aQ0PsRgPc9/j55Ja7jiGZ/FIbzMPf6V+zBugbS4+76rVano

P/1WMNsei0bhtsf+LRIvCMdFKy1GJNSGBHEGZ7Sun6JGqQnixaabfnDw/EhJv6iT

02zNVRFn/dzyn2+oz4Vt5nhvWcwFc2lngmpdSROCPGSk/1l1y14nlYEItiMAUfEl

YJH98+OABVR3PUzYJLVretPeSVrXjFgRMRRMQASyLNVc1byWzWMFhcV4Fvqanp7H

5xLwRfX+IJxrGrMFLiyMTeQ3MjaICNg=

-----END CERTIFICATE-----
1 Mi Piace
99

Ciao Andrea,

innanzitutto grazie mille per la risposta.
C’era effettivamente un’incompatibilità fra il nostro .well-known e il vostro.
Segnalo che abbiamo preso spunto da SPID/CIE OpenID Connect Regole tecniche | Esempi , il quale a questo punto sembra contenere degli errori negli esempi.
Ad ogni modo abbiamo ancora lo stesso errore in fase di onboarding… nonostante il well-known aggiornato: https://cie.collaudo.sourcesense.com/realms/cie-coll-sa/oidcfed/.well-known/openid-federation
Le chiavi per pre-produzione che stiamo utilizzando sono delle keys generate con il tool nativo di keycloak il quale ci stacca anche un certificato self-signed.
Suppongo a questo punto che il problema potrebbe essere questo, me lo confermi?

Grazie ancora,
Robin

100

Noi abbiamo usato i metodi della libreria Core/JWT del progetto GitHub - italia/spid-cie-oidc-php: The SPID/CIE OIDC Federation Relying Party for PHP.
Col metodo getCertificateJWK, opportunamente modificato per eliminare x5c, x5t e x5t#S256, ci creiamo le 2 chiavi.
Per il futuro…elimina gli slash finali negli endpoint di federazione.

101

Abbiamo rimosso gli slash finali negli endpoint di federazione ma l’errore rimane il medesimo purtroppo.
E’ possibile che le chiavi debbano essere generate per forza partendo direttamente dal certificato SSL presente nell’host con il quale ci federiamo come SA?
@IPZS-CIE

102

Non volevo dire che il problema fossero gli slash, ma per il futuro dovrai toglierli (a me IPZS me li fece togliere).
Riguardo le chiavi direi proprio di no, io mi sono generato 2 terne (pubblica, privata e certificato) in autonomia e le ho utilizzate per creare le keys da inserire nell’EC usando quel metodo che ti ho linkato.

Come “Identificativo componente” inserisci https://cie.collaudo.sourcesense.com/realms/cie-coll-sa/oidcfed/ ?

103

Bene, per quanto riguardo le chiavi.
Sì, l’identificativo che inserisco è quello che trovi nel .well-known.
La chiave che inserisco è invece quella che ho postato qualche commento prima (la sig del well-known).
Onestamente ho terminato le prove a disposizione.
Come posso ottenere il supporto di IPZS?

104

Inserisci nella componente tecnica solo la “sig”? Se nell’EC hai “sig” ed “enc” devi inserirle entrambe nella componente tecnica

105

Si stiamo provando sempre con entrambe le casistiche ma senza mai avere successo.
Il formato è lo stesso presente nel .well-known

{
  "keys": [
    {
      "kid": "2DHdzTMF08Dle_ffhAo1vCIWPK0qGa-nBmeSrRmBG-g",
      "kty": "RSA",
      "alg": "RS256",
      "use": "sig",
      "n": "rc9Fn03uMpWTVf49t2KujxdpsAhNYyg_xQyGSanz_iNQOh42t0dUySmVhUSUtSERgetpH4kEh6_rnGKssWXJtk-oH8wyjwGYLheXu6rEq3jitQQx0A-q9XiD1duxi83s5fLiBSd1MpYvUmTKcreDo1aNyH0C9aTFdvQU7YbtVMMv9SPwsM3buI8x2y9THWCjZwpnbakIgTqTtHHrHRD0qTU-ln98aUA-uxhD3Tux5Yu7d7c5DogzWmhqhJhmoEZXkiI-omPoUdJuU822oC_1bKftjQWv1UGZARIRVPufmEV7BjA4CdUbvgXNE4CwQ-BDv607vze5yfyaQtkqPuE_5Q",
      "e": "AQAB"
    },
    {
      "kid": "Biu0-HiShjJSJIPll04my2kURKgJuM3fUwm6v6b5c-I",
      "kty": "RSA",
      "alg": "RSA-OAEP",
      "use": "enc",
      "n": "ogu6sWXfKIQxTVUCU1hdpuJSBCo9XaMIDFJj2KLuVEPnZpwyeXySuThJO-0JgOsF8C_MgnZb7oex2NMnx9qW7COT7sqjr1tCBMA4gOM9Dz_wxzzIoSszLXZOeGSAWf1JVC00momRv7aqdjhEnq14NUpux6XX5gSAz1szcfNhfxIRpz8BDwu-JIAkSnXMiOljo4jD1Kb0wMnYpl0Zn7kYWJD5rSmXKPIIgjs_QxNvfFUdkIjCYlotZ3Wz6reBkMK28PW8x85lfkHmhfW5D4msYM5pl1ScZSJMlMPxBGsIazXF9teB7SkD6R5zH9AE69SIXxfR4F1V5GfSuhVydZX7rw",
      "e": "AQAB"
    }
  ]
}