ho impostato un utente nella directory attiva azzurra, nel mio programma raccoglierò nome utente e password di un utente finale e voglio verificare con la directory attiva di Windows Azure.Come convalidare le credenziali dell'utente di directory attive di Azure?
è possibile? pl fornire qualche riferimento.
so utilizzando i cmdlet di Power-shell possiamo convalidare, voglio sapere c'è qualche altro modo per convalidare utente crednetial
Ah, credo, si sta cercando di implementare uno scenario SSO. Prova Adding Sign-On to Your Web Application Using Windows Azure AD! E se il cliente non dispone di una sottoscrizione di Azure, questo esempio Multi-Tenant Cloud Application for Windows Azure Active Directory descrive i dettagli utilizzando la libreria di autenticazione di Azure Active Directory. Spero che questo ti aiuti.
I tuoi collegamenti sono utili.Ma dal punto di vista dello sviluppatore, sarei più interessato a trovare un modo, dove ho già il nome utente/dominio/password ecc. Con me. Quindi non voglio aprire la finestra del browser e lasciare che l'utente lo faccia (per ora è così). Come eseguire un'autenticazione WAAD, quando abbiamo già tutti i dettagli con noi? Attualmente stiamo usando 'AuthenticationContext.AcquireToken (risorsa, id-cliente, risorsa-app-id-uri)', ma come usare 'AuthenticationContext.AcquireToken (resource, ClientCredential)'? – iammilind
Il collegamento [this] (http://code.msdn.microsoft.com/AAL-Server-to-Server-9aafccc1/sourcecode?fileId=93566&pathId=1250178454) fornisce l'esempio di codice, ma non è sicuro che sia applicabile o no. Non sono sicuro di come usare la parte 'clientSecret' per creare' ClientCredential'. – iammilind
Si dice che "si raccolgono nome utente e password di un utente finale e si desidera verificare con la directory attiva di Windows Azure" - Sono abbastanza sicuro che ciò non sia possibile, e so per certo che non è consigliabile. Questo è l'opposto della tendenza di approcci come OAuth in cui gli utenti possono accedere a molte applicazioni utilizzando le stesse credenziali (e la parte in arrivo è fondamentale) senza mai rivelare a quelle "molte applicazioni" la loro password.
Questa è l'idea di autenticazione federata ed è un modello più sicuro rispetto agli approcci più vecchi di consentire a tutte le app con cui si effettua l'accesso di accedere direttamente al proprio nome utente e password. In genere in un tale flusso, assumendo un account Office 365 esistente, la nuova app che hai creato e configurato per l'autenticazione tramite O365 reindirizzerà il browser Web dell'utente a O365 in cui l'utente digita il nome utente e la password di O365, quindi accetta (una volta) che è giusto che vengano utilizzati con questa nuova app, quindi il browser reindirizzerà nuovamente all'app, con un token di sicurezza con alcune affermazioni in esso. Queste affermazioni includeranno il nome, l'indirizzo email e altre informazioni sull'utente che ha effettuato l'accesso e sono intese come sufficienti per identificare l'utente nella tua app.
Lo stesso vale per l'autenticazione con, ad esempio, Facebook o Google: l'app non visualizzerà mai direttamente la password dell'utente. Si applicherebbe anche al log in StackOverflow stesso, quindi hai visto il flusso di lavoro.
Spero che questa opzione ADAL possa essere d'aiuto.
ClientCredential encryptedCredentials = Convert.ToBase64String(System.Text.ASCIIEncoding.ASCII.GetBytes(string.Format("{0}:{1}", "[email protected]", "PasswordX")));
httpClient.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Basic", encryptedCredentials);
Nel caso qualcuno stia ancora cercando una risposta. Il supporto per l'autenticazione dell'utente senza aprire una nuova finestra per l'utente cred è stato aggiunto in ADAL versione 2.7.10707.1513-rc fornendo un oggetto della classe UserCredential a una funzione sovraccaricata di AcquireToken.
public AuthenticationResult AcquireToken(string resource, string clientId, UserCredential userCredential);
Ecco un codice di esempio per PowerShell. $UserCred = new-object Microsoft.IdentityModel.Clients.ActiveDirectory.UserCredential("****@*****", "*****") $result = $AuthContext.AcquireToken($resource,$clientID,$UserCred)
Questo è disponibile solo per i client nativi, non per le app Web. – BenV
Che cosa stai cercando di realizzare? Puoi descrivere il design di livello superiore del tuo schema di autenticazione e autorizzazione. Sulla base della tua descrizione sembra che tu stia cercando qualcosa di abbastanza insicuro e "cattivo". C'è un motivo per cui non si sta utilizzando l'autenticazione basata sulle attestazioni nell'appliance relying party e si lascia che la directory attiva di Windows Azure (WAAD) gestisca l'autenticazione? – Nathan
Nella maggior parte delle applicazioni che ho distribuito per aziende di grandi dimensioni, abbiamo lasciato che sia la fonte di autenticazione AD in locale e non vedo l'ora di capire esattamente come Azure AD può sostituirlo nelle applicazioni cloud. Preferisco non scrivere il codice di autenticazione se non devo, e lasciare che WAAD si occupi di tutto ciò per me, mentre mi concentro su come l'autorizzazione si applica alla logica della mia applicazione. – Graham
Hai mai trovato una soluzione per questo. Sto cercando di fare la stessa cosa? – Gotts