ADFS 2012 R2 (3.0) Convalida del token Web JSON

Question

ADFS 2012 R2 (3.0) Convalida del token Web JSON

#1 da (2 voti)
#2 da (1 voti)
#3 da (0 voti)

4

Il nostro cliente vorrebbe che usassimo ADFS 2012 R2 (alias 3.0) come mezzo principale per due funzioni di sicurezza nelle app interne che stiamo costruendo:

L'app web (ci sono due .NET e Angular) e un'app iOS useranno il flusso OAUTH all'interno di ADFS
Al completamento del flusso di token, il JWT creato da ADFS verrà passato a un'API RESTful che viene creata con Spring
L'API Spring dovrà quindi convalidare il JWT prima di consentire alla chiamata di procedere

L'uso di ADFS per il flusso di OAUTH è nuovo per noi e alcune domande sono apparse. Abbiamo setacciato gli Internets in cerca di risposte. Molti di loro sono focalizzati sulla fornitura di una soluzione utilizzando MS solo tecnologia (API ADAL, .NET / C #, OWIN, Katana). Pertanto, speravamo di far affluire una risposta via SE. Qualsiasi aiuto è molto apprezzato.

A questo punto, siamo stati in grado di:

Registrare un client OAUTH con il comando PowerShell in ADFS
Registra una risorsa "falsa" come parte ricorrente in ADFS
Imposta i nostri client per effettuare una chiamata ad ADFS per autorizzare e ottenere il JWT restituito

Questo collegamento è stato molto utile per spiegare la configurazione:

link

Ora, dobbiamo inserire il codice nell'API di Spring per verificare il JWT.

In tutti gli esempi di flusso OAUTH, esiste un segreto condiviso tra l'emittente e il cliente. Questo segreto viene utilizzato per verificare che il JWT non sia stato falsificato.

Nel setup che abbiamo fatto finora in ADFS, non esiste una definizione di chiave segreta o segreto condiviso. Possiamo prendere il JWT dall'intestazione dell'autorizzazione e decodificarlo. Ma sembra che non abbiamo mezzi per verificare la firma.

La domanda è: come convalidare il JWT all'interno dell'API Spring (passato dal client tramite l'intestazione) che ritorna da ADFS senza avere il "segreto" che è stato usato per costruire la firma?

Le nostre opzioni se non lo facciamo funzionare sono:

Utilizza Oracle Identity Manager / Access Manager (già in-house)
Porta WSO2 Identity Manager nell'immagine

oauth json adfs

posta soglm 26.01.2015 - 21:11

fonte

3 risposte

Leggi altre domande sui tag oauth json adfs

OpenSSL con crittografia AES-256-CTR Quali informazioni potrebbero essere ottenute da un'etichetta di spedizione Amazon?

score 2 · Answer 1

Se comprendo correttamente la tua domanda, la firma è un RSASSA che utilizza l'hash SHA-256 basato sul configurato. Certificato di firma token .

Ho un esempio di convalida Node.js su GitHub ed ecco un post di blog con alcuni altri dettagli.

score 1 · Answer 2

Ho cercato di rispondere a questa stessa domanda negli ultimi due giorni. Sembra che l'implementazione di OAUTH2 di Windows Server 2012 R2 ADFS 3.0 richieda l'uso di certificati anziché di un segreto condiviso se si desidera crittografare / firmare la risposta JWT. Avendo utilizzato OAUTH2 con più applicazioni Web non Microsoft, ho sempre visto segreti condivisi e non certificati. Scommetto che lo standard OAUTH2 consente entrambi, ma Microsoft ha scelto di andare con ciò che sanno nella prima implementazione dello standard.

Finora, ho visto una citazione da un blog dei dipendenti Microsoft che mi fa pensare che ciò che vediamo come "standard" OAUTH2 non è supportato da ADFS 3.0:

Da link

JWTs issued by ADFS on Windows Server 2012 R2 are signed using ADFS' issuing certificate. ADFS does not support JWT encryption.

Inoltre, Novità di ADFS per Windows Server 2016 sottolinea che i segreti condivisi saranno una nuova funzionalità:

(Ci scusiamo per i link non linkati. Poiché non ho alcuna reputazione qui, posso includere solo un link in questo post.) Da technet.microsoft.com/en-us/library/mt617220.aspx (Enfasi mia.)

AD FS for Windows Server 2016 builds upon the Oauth protocol support that was introduced in Windows Server 2012 R2, to enable the most current and industry standard based authentication flows among web apps, web APIs, browser and native client based apps. Windows Server 2012 R2 offered support for the Oauth authorization grant flow and authorization code grant type, for public clients only. In Windows Server 2016, the following additional protocols and features are supported:

OpenId Connect support

Additional Oauth authorization code grant types

Implicit flow (for single page applications)

Resource Owner password (for scripting apps)

Oauth confidential clients (clients capable of maintaining their own secret, such as app or service running on web server)

Oauth confidential client authentication methods

Symmetric ( shared secret / password)

Asymmetric keys

Windows Integrated Authentication (WIA)

Support for "on behalf of" flows as an extension to basic Oauth support.

For more see Enabling Oauth Confidential Clients with AD FS 2016 and Enabling OpenId Connect with AD FS 2016

Come sviluppatore, la configurazione di una casella IIS nel dominio con una pagina di gestione (ASHX) che verifica l'utente del dominio e reindirizza l'utente all'app Web con un JWT crittografato utilizzando la chiave condivisa è una soluzione semplice fino a quando Windows Server 2016 è disponibile. Abbiamo codice di esempio su come farlo sul nostro forum dell'applicazione: connectionsonline.zendesk.com/entries/82271995-Single-Sign-on-Authentication-SSO-with-OAuth-2-0

score 0 · Answer 3

Se riesci a ottenere il token JWT, la vita diventa facile con WebAPI, per l'applicazione C # può usare il seguente codice (pacchetto Owin nuget)

app.UseActiveDirectoryFederationServicesBearerAuthentication(
new ActiveDirectoryFederationServicesBearerAuthenticationOptions
{
    Audience = "The AppId Registered In ADFS",
    MetadataEndpoint = "https://fs.domain.com/federationmetadata/2007-06/federationmetadata.xml"
});

vedi blog protezione-a-web-api-con-adfs su windows server 2012-r2 qui