Quello che mi ha spinto a replicare è stata questa parte

...vengono recuperati dei dati in base al nome utente che viene memorizzato in una variabile.
In questo scenario penso che Session non sia da prendere in considerazione perche per prima cosa potrebbe essere wippato dal server in qualsiasi momento creando appunto situazioni di inconsistenza. Ma la cosa piu importante è che la session potrebbe perdurare tra diversi login creando problemi di sicurezza molto gravi: un utente potrebbe accedere ad informazioni riservate di un altro utente (quello loggato precedentemente). Questo perche il cookie di sessione e quello di autenticazione sono due cose diverse. Anche se asp.net mi promettesse di wippare il cookie di sessione ad ogni login/logout (cosa che non ho letto da nessuna parte) o se dovessi farlo io a mano, non mi fiderei comunque. Questo è un problema ricunducibile alla ridondanza delle informazioni: potrebbe succedere una qualsiasi cosa che faccia perdere la sincronizzazione e la sicurezza verrebbe compromessa.

In questo caso la cosa migliore è usare User.Identity.Username per prelevare il nome utente della richiesta http corrente mentre per prelevare/memorizzare informazioni che vanno memorizzate in db e sono legate all'utente si potrebbe usare il Profile oppure query al proprio database su tabelle in cui l'username è la chiave esterna, l'importante è che da aspnet, quando si deve passare questa chiave esterna ai metodi di business, si usi sempre User.Identity.Username che da la certezza sull'identità di chi ha effettuato la richiesta su cui si sta operando.

ora vado a lavarmi le mani sporche di viscere