2016-05-02 43 views
8

Sto quasi immaginando come funzionano i diversi componenti di un'architettura server di autenticazione e autorizzazione. Credo davvero che IdentityServer sia un ottimo software.IdentityServer 3 + Asp.net Identity: Ambiti, reclami e clienti - Chiarimenti

Sto cercando di riassumere le mie scoperte, per sistemare una base per le mie domande.

  1. IdentityServer genera token utilizzando OpenID Connect. I token emessi sono token ID e token di accesso.
  2. I token sono richiesti, come indicato dal protocollo OpenID Connect, ai client utilizzando i flussi OAuth 2.0. Un flusso per ogni cliente.
  3. Durante l'inizio del flusso, il client richiede una raccolta di ambiti (almeno "openid", perché deve dichiarare che è stato attivato un flusso OpenID Connect)
  4. Un client può chiedere a tutti gli ambiti che è autorizzato chiedere. Utilizzando il plug-in Entity Framework per IdentityServer, queste informazioni sono contenute nella tabella ClientScope. Se il client richiede un ambito che non è autorizzato a richiedere, il flusso viene interrotto.
  5. Gli ambiti possono contenere "rivendicazioni". Ciò significa che se un ambito contiene un gruppo di attestazioni, ogni volta che al client viene rilasciato un token, questo token contiene anche tutte le attestazioni dell'utente corrispondente. Ad esempio: consenti ai "ruoli" di chiamare un ambito che contiene la rivendicazione "ruolo". Non appena il client è autorizzato, il token ricevuto conterrà tutti i ruoli dell'utente (come attestazioni).
  6. Ogni ambito richiesto, se autorizzato, viene "tradotto" in un reclamo con il nome "ambito". Ciò significa che se un client richiede, ad esempio, un ambito definito "api", l'identità generata avrà almeno un reclamo chiamato "scope" con valore "api".

Se tutto quello che ho scritto è più e meno corretto, qui sono le mie domande:

  1. come vengono definiti reclami sui tavoli di identità ASP.NET (cioè AspNetUserClaims) collegati a quelli IdentityServer . Per quello che ho visto l'abbinamento è fatto sul nome. Questa conclusione è corretta? In altre parole, se il mio cliente deve ricevere una dichiarazione di "ruolo" (perché ha richiesto l'ambito "ruoli"), il plug-in "Identità Asp.Net" per IdentityServer pubblicherà semplicemente le attestazioni di "ruolo" definite per l'autenticazione utente?
  2. che fa riferimento alle tabelle di plug-in "EntityFramework", qual è il significato della tabella "ClientClaims"? Non riesco a capire come le attestazioni possano essere direttamente collegate al cliente ... Cosa mi manca?
  3. supponiamo che nel mio server di risorse Ho un'azione protetta con un attributo ResourceAuthorize come questo:

    [ResourceAuthorize ("Leggi", "Ordini")]

    Nel mio AuthorizationManager I check in la presenza di un reclamo "order_read" o un claim "api". Questi sono due diversi ambiti definiti nel mio AuthorizationServer, uno solo per "lettura ordine" e l'ultimo per un accesso API completo. Il primo può essere richiesto da clienti di terze parti, mentre il secondo no. È una buona pratica?

  4. Non riesco a capire cosa dovrebbe fare il mio client con id_token. Dovrei ignorare il problema, dato che sto usando la libreria js OIDC Token Manager? I controlli di sicurezza sono eseguiti da questa libreria?

  5. Ultima domanda: quando la mia applicazione presenta il token di accesso, come viene generato ClaimsIdentity? È giusto dire che è generato dopo aver convalidato il token su Identity Server?Ciò significa che IdentityServer otterrà il token di accesso e lo tradurrà in una serie di attestazioni?

Grazie per i chiarimenti!

Marco

risposta

6

Sì, ne hai il succo. Per quanto riguarda le vostre domande:

come sono indicazioni definite su tavoli asp.net identità

Ecco a voi. IdentityServer non richiede una libreria di gestione delle identità. Il punto di estensibilità IUserService è il punto in cui si colma il divario. Abbiamo una versione iniziale di IUserService, ma si tratta di un NuGet basato su codice in modo che tu possa cambiarlo per fare davvero ciò di cui hai bisogno.

non riesco a capire quello che il mio cliente dovrebbe fare con l'id_token

È utilizzato principalmente per passare di nuovo a IdentityServer al momento signout (per autenticare la richiesta signout).

quando la mia applicazione presenta il token di accesso, come è il ClaimsIdentity generato

C'è middleware (AccessTokenValidation) per convalidare il token di accesso. Il risultato sono le attestazioni del token, che vengono quindi convertite in ClaimsIdentity e rese disponibili per qualsiasi elaborazione downstream (come il codice API Web).

qual è il significato della "ClientClaims" tavolo

La configurazione Client ha una proprietà Claims se si desidera emettere crediti per conto del cliente. Controllare la documentazione: https://identityserver.github.io/Documentation/docsv2/configuration/clients.html

supponiamo che nel mio server di risorse Ho un'azione protetta con un attributo ResourceAuthorize come questo

Questo non è correlato alla IdentityServer, ed è parte della libreria IdentityModel. ResourceAuthorize è un framework per l'utilizzo dell'utente, della risorsa e dell'azione che viene eseguita nell'account quando si tenta di decidere il risultato dell'autorizzazione.

+0

Ehi, grazie per il tuo feedback! Lo apprezzo molto! 1. Sì, capisco che non vi è alcun mandato sulla libreria di gestione delle identità. Mi stavo chiedendo come sono mappate le affermazioni "richieste" definite nell'ambito degli Scopes ai claim di identità di Asp.net. Per quello che ho visto questa mappatura è fatta solo sul nome. Corretta? 2. Non riesco davvero ad avere il senso dell'id_token ... Hai qualche risorsa in cui posso capire meglio? 3. Ok! Questo è quello che stavo pensando. 4. Reclami da parte del cliente: quindi se voglio che un client abbia sempre dei reclami, anche se non sono contenuti negli ambiti richiesti? 5. OK! – Marconline

Problemi correlati