Case study

Adozione Keycloak su Backend .NET

Un backend .NET con autenticazione gestita in casa: logica di sessione sparpagliata nel codice, niente standard per l'integrazione di nuovi client, e nessuna risposta chiara quando arrivava la domanda 'come gestiamo SSO o servizi terzi?'

Keycloak.NETC#DockerPostgreSQLOAuth2
GitHub Articoli correlati →

Contesto

Sistema applicativo già in produzione, con utenti reali. La migrazione doveva avvenire senza interrompere il servizio e senza forzare il logout di tutti gli utenti attivi. Il codice di autenticazione era cresciuto nel tempo senza un disegno coerente.

Pilastro applicato

Verificare

Cosa ho fatto

  • Mappatura del modello di autenticazione esistente per capire cosa Keycloak avrebbe sostituito e cosa no
  • Configurazione di Keycloak come identity provider con realm, client e mapper coerenti con il dominio
  • Migrazione del flusso applicativo a OAuth 2.0 / OpenID Connect, con strategia di rollout che preserva le sessioni attive
  • Documentazione del nuovo modello di permessi per il team — perché funzionasse anche dopo che me ne fossi andato

Risultato

L'autenticazione è diventata un componente standardizzato e isolato dal resto della codebase. Aggiungere un nuovo client (mobile, partner, servizio interno) è ora una configurazione, non un progetto. Il team ha autonomia sui permessi senza dover toccare codice applicativo.

Progetto di adozione di Keycloak come identity provider su un backend .NET esistente. Ho gestito l’analisi dell’architettura di autenticazione, la migrazione a OAuth 2.0 e OpenID Connect, e l’integrazione completa con il flusso applicativo esistente.

Stai affrontando qualcosa di simile?

Se questo case study tocca un problema che hai sul tavolo, parliamone in una discovery call gratuita di 30 minuti.