Identity Design ASP.NET

4

Sto provando a progettare un sistema con le funzioni sottostanti e attualmente sto cercando di capire il modo migliore per gestire Identity:

  1. Ci saranno più parti disaccoppiate del sistema, con gli stessi clienti che accedono a varie parti
  2. Vorrei che gli utenti fossero organizzati da organizzazioni / aziende, ovvero user1 & utente2 appartiene a ORG1
  3. Desidero che ulteriori informazioni siano memorizzate all'interno di un profilo utente, le informazioni provengano da vari sistemi, nonché informazioni globali come l'indirizzo, ecc.
  4. Per i ruoli non ho ancora deciso se saranno gestiti da singole app o globalmente e specializzati in alcune app

Il mio enigma è se usare la nuova MVC Identity rilasciata in ASP.NET Beta attualmente in uscita, o usare WIF o Active Directory. Presumo che un'applicazione centralizzata gestisca gli utenti e amp; le loro attività di amministrazione associate e quindi la federazione ad altre applicazioni sono le migliori. Se capisco correttamente qualcuno dei 3 è in grado di farlo.

Quello che mi chiedo è quale usare per essere più flessibile. Fondamentalmente qualcosa che può essere espanso in seguito e non ha un'enorme curva di apprendimento, possibilmente per dispositivi mobili e amp; uso delle API. Non conosco abbastanza WIF o AD perché non li ho mai veramente usati e ASP.NET Identity è ancora in beta e non è documentato al 100%. La mia esperienza con i sistemi di autenticazione sta funzionando con quelli pronti per l'uso. Non ho mai avuto davvero a che fare con SSO o federazione

Una cosa che volevo aggiungere è che non è necessario registrarsi all'esterno. La registrazione sarà gestita esclusivamente dagli amministratori, non è sicuro che ciò si verifichi, ma ha pensato che potrebbe essere importante

    
posta user60812 27.08.2013 - 14:53
fonte

1 risposta

1

Questa suite di applicazioni sembra sufficientemente complessa da giustificare un livello di oggetti di business. Hai bisogno di un progetto separato che contenga i tuoi modelli di business. Due dei tuoi modelli di business sarebbero Utente e Organizzazione . L'utente avrebbe un riferimento all'oggetto alla sua organizzazione.

Progettare la classe User per avere tutte le proprietà necessarie ignorando il fornitore sottostante. Una volta terminato il design della classe, se MVC Identity è sufficiente per le tue esigenze, ti consiglio di utilizzarlo. Se non lo è, non provare a forzarlo, tira il tuo.

In ogni caso, le tue chiamate dovrebbero avere un aspetto simile a questo:

BusinessModels.MyUser user = MyUserRepo.GetUserByUsername(MVCIdentity.CurrentUser.Username);
    
risposta data 12.06.2015 - 15:23
fonte

Leggi altre domande sui tag