Questa pagina è stata utile?
I suggerimenti relativi al contenuto di questa pagina sono importanti. Comunicaceli.
Altri suggerimenti?
1500 caratteri rimanenti
Esporta (0) Stampa
Espandi tutto

Note sulla versione

Pubblicato: aprile 2011

Aggiornamento: giugno 2015

Si applica a: Azure

Questo argomento descrive le nuove funzionalità presenti in ogni versione di Microsoft Azure Active Directory Access Control (anche noto come Servizio di controllo di accesso o ACS), illustra le differenze di ogni versione del prodotto rispetto alle precedenti ed evidenzia le eventuali modifiche di rilievo che potrebbero influire sul codice scritto per una versione precedente.

In ACS è stata implementata una funzionalità per consentire ai proprietari di spazi dei nomi ACS di eseguire la migrazione delle configurazioni di provider di identità Google da OpenID 2.0 a OpenID Connect. I clienti potranno eseguire la migrazione degli spazi dei nomi ACS a OpenID Connect fino al 1° giungo 2015 e la migrazione del relativo codice di back-end per l'uso di identificatori OpenID Connect fino al 1° gennaio 2017. Se non si esegue l'azione appropriata prima di ciascuna di queste scadenze, si verificheranno problemi di funzionamento delle applicazioni. Per informazioni aggiuntive dettagliate, vedere Migrazione degli spazi dei nomi ACS in OpenID Connect di Google.

A partire dal 19 maggio 2014 i nuovi spazi dei nomi ACS non potranno più usare Google come provider di identità. Gli spazi dei nomi ACS registrati prima del 19 maggio 2014 potranno continuare a usare Google come provider di identità. Questa nuova limitazione è stata implementata perché Google sta eliminando gradualmente il supporto per OpenID 2.0, da cui dipende ACS, e ha chiuso la registrazione di nuove applicazioni. Gli spazi dei nomi ACS esistenti che usavano Google continueranno a funzionare fino al 20 aprile 2015. Se l'applicazione richiede il supporto per gli account Google, è consigliabile registrare l'applicazione direttamente su Google.

Se un utente prova a effettuare l'accesso a un nuovo spazio dei nomi ACS usando il proprio account Google, verrà reindirizzato a una pagina di errore HTTP 400.

Nuovo spazio dei nomi ACS ed errore di Google

Per aumentare la disponibilità e le prestazioni di ACS per tutti gli utenti, è stato implementato un limite di 30 richieste token al secondo per ogni spazio dei nomi. Se uno spazio dei nomi supera questo limite per un periodo di tempo prolungato, ACS respinge le richieste di token inviate dallo spazio dei nomi per la durata dell'intervallo e restituisce un errore HTTP 429/ACS90055 "Numero eccessivo di richieste". Per altre informazioni, vedere Limitazioni del servizio ACS e Codici di errore di ACS.

Nuove funzionalità

L'aggiornamento di dicembre 2012 di ACS include le nuove funzionalità descritte di seguito:

Supporto per il Single Sign-Out federato usando il protocollo WS-Federation

Le applicazioni Web che usano ACS per consentire il Single Sign-On (SSO) con i provider di identità che usano il protocollo WS-Federation possono ora sfruttare le funzionalità di Single Sign-Out. Quando un utente esce da un'applicazione Web, ACS può disconnettere automaticamente l'utente dal provider di identità e dalle altre applicazioni relying party che usano lo stesso provider di identità.

Questa funzionalità è abilitata per i provider di identità WS-Federation, inclusi Active Directory Federation Services 2.0 e Windows Live ID (account Microsoft). Per consentire il Single Sign-Out, ACS esegue le attività seguenti per gli endpoint del protocollo WS-Federation:

  • ACS riconosce i messaggi wsignoutcleanup1.0 inviati dai provider di identità e risponde inviando messaggi wsignoutcleanup1.0 alle applicazioni relying party.

  • ACS riconosce i messaggi wsignout1.0 e wreply inviati dalle applicazioni relying party e risponde inviando messaggi wsignout1.0 ai provider di identità e messaggi wsignoutcleanup1.0 alle applicazioni relying party.

Per altre informazioni, vedere Esempio di codice: ASP.NET MVC 4 con disconnessione federativa e l'articolo relativo all'autenticazione passiva per ASP.NET con WIF.

Interruzione del supporto per ACS 1.0

Il supporto per il Servizio Access Control 1.0 è stato interrotto per questa versione, incluso il supporto alla migrazione dal Servizio Access Control 1.0 al Servizio Access Control 2.0.

Passare allo Spazi dei nomi controllo di accesso nel nuovo portale di gestione di Azure

Il nuovo portale di gestione di Azure (http://manage.WindowsAzure.com) include una route al familiare portale di gestione ACS dove si eseguono la creazione e la gestione dello Spazi dei nomi controllo di accesso.

Per passare al portale di gestione ACS:

  1. Passare al portale di gestione di Microsoft Azure (https://manage.WindowsAzure.com), eseguire l'accesso, quindi fare clic su Active Directory. (Suggerimento per la risoluzione dei problemi: elemento "Active Directory" mancante o non disponibile)

  2. Fare clic su uno Spazi dei nomi controllo di accesso e quindi fare clic su Gestisci.

Per creare uno spazio dei nomi di Controllo di accesso, fare clic su Nuovo, Servizi app, Controllo di accesso, quindi su Creazione rapida. Altrimenti, fare clic su Spazi dei nomi controllo di accesso prima di scegliere Nuovo.

Per informazioni sulle attività di gestione ACS nel portale di gestione di Microsoft Azure, fare clic su Active Directory, quindi su Guida (?). Altrimenti, fare clic su Active Directory, su Spazi dei nomi controllo di accesso, quindi su ?.

Passare allo Spazi dei nomi controllo di accesso per un service bus

Quando si crea uno spazio dei nomi del bus di servizio in , il portale crea automaticamente uno Spazi dei nomi controllo di accesso per il bus di servizio.

Per configurare e gestire lo Spazi dei nomi controllo di accesso per un bus di servizio:

  1. Accedere al portale di gestione di Azure.

  2. Fare clic su Bus di servizio e quindi selezionare un bus di servizio.

  3. Fare clic su Chiave di accesso, quindi su Apri portale di gestione ACS.

Per verificare che lo Spazi dei nomi controllo di accesso sia associato al bus di servizio, vedere il campo Spazio dei nomi del servizio nella parte superiore della pagina Servizio di controllo di accesso. Il nome dello spazio dei nomi è costituito dal nome del bus di servizio con un suffisso "-sb".

Per altre informazioni, vedere Procedura: Gestire lo spazio dei nomi ACS per un'istanza del bus di servizio.

Miglioramenti del portale di gestione ACS per visualizzare le chiavi del provider di identità WS-Federation e nascondere le password

Questa versione contiene un paio di miglioramenti relativi alla visualizzazione e all'elaborazione di certificati, chiavi e password nel portale di gestione ACS 2.0:

  • I certificati per la firma sono ora visibili nella sezione relativa alla modifica del provider di identità WS-Federation: in passato, i certificati importati dai metadati WS-Federation usato per convalidare la firma dei token e rilasciati da tale provider di identità non erano visibili nel portale di gestione ACS. Nella sezione di modifica del provider di identità WS-Federation sono ora contenute informazioni sui certificati importati, inclusi le date di scadenza e lo stato. È ora possibile aggiornare questi certificati usando la nuova casella di controllo che consente di reimportare i dati dall'URL dei metadati WS-Federation al salvataggio.

  • Le password e le chiavi di firma simmetrica sono ora nascoste per impostazione predefinita: per impedire la divulgazione accidentale di password e chiavi simmetriche, questi valori sono ora nascosti per impostazione predefinita nelle schermate di modifica di tutto il portale. Per visualizzare intenzionalmente il valore di una password o di una chiave simmetrica (ad esempio, in modo da copiarla in un'applicazione), è ora necessario selezionare un pulsante "Mostra password" o "Mostra chiave".

Possibilità di eseguire la federazione di tenant di directory con lo Spazi dei nomi controllo di accesso

È ora possibile usare i tenant di Azure Active Directory come provider di identità nello Spazi dei nomi controllo di accesso. In tal modo sarà possibile prevedere molti scenari, tra cui l'abilitazione dell'applicazione Web ad accettare sia le identità aziendali dai tenant di directory sia le identità utente dai provider social come gli account di Facebook, Google, Yahoo!, Microsoft o di qualsiasi altro provider OpenID. Istruzioni dettagliate su come implementare lo scenario illustrato sono disponibili in questo post relativo al provisioning di un tenant di Azure Active Directory come provider di identità in uno spazio dei nomi ACS.

Supporto del protocollo SAML 2.0 per le applicazioni relying party (anteprima per sviluppatori)

ACS ora supporta il protocollo SAML 2.0 per il rilascio di token alle applicazioni relying party. Il supporto del protocollo SAML 2.0 è stato rilasciato in anteprima per gli sviluppatori, e quindi le informazioni relative alla sua implementazione sono ancora soggette a modifica. Per informazioni dettagliate, vedere Developer Preview: Protocollo SAML.

Problemi noti

Nell'aggiornamento di Microsoft Azure Active Directory Access Control (anche noto come Servizio di controllo di accesso o ACS) del mese di dicembre 2012 sono stati identificati i problemi noti elencati di seguito:

I coamministratori di Azure possono ora gestire lo Spazi dei nomi controllo di accesso. Tuttavia, è richiesta un'azione per propagare i coamministratori preesistenti in uno Spazi dei nomi controllo di accesso preesistente.

Prima dell'aggiornamento di novembre 2012 è stato risolto un problema per cui, per impostazione predefinita, solo l'amministratore del servizio Azure poteva gestire uno Spazi dei nomi controllo di accesso creato nella sottoscrizione. Se un coamministratore di Azure avesse provato ad accedere al portale di gestione ACS per ottenere uno Spazi dei nomi controllo di accesso avrebbe ricevuto uno dei codici di errore ACS seguenti:

  • ACS50000: Errore durante il rilascio di un token.

  • ACS60000: Si è verificato un errore durante l'elaborazione delle regole per la relying party che usa l'autorità emittente "uri:WindowsLiveID"

  • ACS60001: Nessuna attestazione di output generata durante l'elaborazione delle regole.

Questo problema è stato risolto per la creazione di un nuovo Spazi dei nomi controllo di accesso da parte di qualsiasi amministratore o coamministratore del servizio Azure. Tuttavia, i clienti con spazi dei nomi esistenti prima della soluzione devono eseguire la soluzione alternativa descritta di seguito affinché i dati del coamministratore vengano propagati a tali spazi dei nomi:

  1. Accedere al portale di Azure (https://windows.azure.com/) usando le credenziali dell'amministratore del servizio o dell'amministratore dell'account.

  2. Rimuovere e aggiungere nuovamente il coamministratore usando le indicazioni fornite in Come aggiungere e rimuovere coamministratori per le sottoscrizioni Azure (http://msdn.microsoft.com/it-it/library/windowsazure/gg456328.aspx)

  3. Uscire e accedere al portale di Azure usando le credenziali del coamministratore. Sarà quindi possibile gestire lo Spazi dei nomi controllo di accesso.

Nel mese di settembre 2012, Microsoft Azure Active Directory Access Control (anche noto come Servizio di controllo di accesso o ACS) è stato aggiornato con le modifiche seguenti:

L'attributo entityID nei metadati WS-Federation pubblicato da ACS è ora scritto in caratteri minuscoli in modo coerente

L'attributo "entityID" nei metadati WS-Federation pubblicato dallo Spazi dei nomi controllo di accesso è ora scritto sempre in caratteri minuscoli. Nelle versioni precedenti, venivano usate le maiuscole/minuscole immesse alla creazione dello spazio dei nomi nel portale di Azure. L'attributo "entityID" identifica lo Spazi dei nomi controllo di accesso alle applicazioni relying party. Di seguito ne è riportato un esempio.

<EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" entityID="https://lowercase-namespace.accesscontrol.windows.net/" ID="_e4a0006c-c23c-41c0-8f87-baa110afaf1d">

Questa modifica si è resa necessaria per risolvere potenziali problemi di convalida del token, in cui il formato maiuscolo/minuscolo dello Spazi dei nomi controllo di accesso nel token rilasciato da ACS (sempre in minuscolo) non corrisponde al formato dello Spazi dei nomi controllo di accesso importato dalla relying party. Le relying party che usano Windows Identity Foundation non sono interessate dai problemi relativi all'utilizzo di maiuscole e minuscole.

I certificati X.509 caricati in ACS ora sono caratterizzati da una limitazione delle dimensioni della chiave pubblica di 4096 bit

Tutti i certificati X.509 caricati in uno Spazi dei nomi controllo di accesso tramite il portale di gestione o il servizio di gestione ACS sono ora obbligati ad avere una chiave pubblica di dimensioni non superiori a 4096 bit. Ciò include i certificati usati per la firma, la crittografia e la decrittografia dei token.

In Windows, è possibile verificare le dimensioni della chiave pubblica di un certificato aprendo il file con estensione cer e selezionando la scheda "Dettagli", quindi controllando il valore del campo "Chiave pubblica". I certificati che usano l'algoritmo di firma sha256RSA sicuro avranno una chiave pubblica a 2048 bit.

Qualsiasi certificato esistente con una chiave di dimensioni superiori a 4096 bit continuerà a funzionare in ACS, ma non potrà essere salvato di nuovo in ACS finché non sarà stato rimpiazzato con un certificato conforme.

Modifiche minime apportate all'algoritmo di selezione della "chiave primaria" usato alla firma di un token in ACS mediante un certificato X.509

Nel portale di gestione e nel servizio di gestione ACS è presente un campo "Make Primary" per i certificati di firma dei token che, quando selezionato, fa sì che ACS firmi i token che usano tale certificato. Con questa versione, se il campo "Make Primary" non è selezionato per nessun certificato di firma del token primario, lo Spazi dei nomi controllo di accesso userà il certificato di firma del token primario esistente contrassegnato dalla prima data di inizio valida per firmare il token. ACS comunque non firma token con un certificato di firma del token non primario se esiste un certificato primario, ma che non è valido o è scaduto.

JWT Beta: modifiche al comportamento di firma quando si usa uno certificato o una chiave dello spazio dei nomi globale per firmare un token JWT

Quando il supporto beta per il token Web JSON (JWT) fu rilasciato nel giugno 2012, ACS usava il seguente ordine di precedenza per determinare quale chiave usare per la firma di ciascun token JWT rilasciato a ogni applicazione relying party:

  • Chiave di firma simmetrica assegnata alla relying party, se disponibile

  • Certificato di firma X.509 assegnato alla relying party, se disponibile

  • Chiave di firma simmetrica assegnata allo Spazi dei nomi controllo di accesso

  • Certificato di firma X.509 assegnato allo Spazi dei nomi controllo di accesso

A partire da questa versione, le chiavi simmetriche a livello di spazio dei nomi non sono più supportate per la firma dei token JWT. Di seguito è riportato il nuovo ordine di precedenza per la firma dei token JWT:

  • Chiave di firma simmetrica assegnata alla relying party, se disponibile

  • Certificato di firma X.509 assegnato alla relying party, se disponibile

  • Certificato di firma X.509 assegnato allo Spazi dei nomi controllo di accesso

Nel mese di giugno 2012, ACS è stato aggiornato con la nuova funzionalità seguente:

Formato JWT ora disponibile per le applicazioni relying party (Beta)

Questo aggiornamento introduce il supporto per il formato BETA del token Web JSON (JWT) in ACS. JWT è un formato di token leggero con codifica JSON, che può essere firmato con un certificato X.509 o una chiave simmetrica e può essere rilasciato da ACS alle applicazioni relying party su uno dei protocolli seguenti:

  • OAuth 2.0

  • WS-Federation

  • WS-Trust

Il formato del token JWT è ora un'opzione selezionabile nella sezione Applicazioni relying party del Portale di gestione ACS ed è anche configurabile attraverso il Servizio di gestione ACS.

Per altre informazioni sul formato del token JWT, vedere le specifiche del token Web JSON. In futuro verranno presentati esempi di codice ACS che includono i token JWT.

ImportantImportante
Il supporto JWT è contrassegnato come "Beta" in ACS, e dunque tutti i dettagli dell'implementazione JWT sono soggetti a modifiche. Gli sviluppatori sono invitati a sperimentare con questo formato di token. Tuttavia, non è consigliabile usare il formato JWT nei servizi di produzione, perché il comportamento potrebbe cambiare senza preavviso.

Agli inizi del mese di maggio 2012, ACS è stato aggiornato con la modifica seguente:

Modifiche alle proprietà degli ID entità esposte tramite servizio di gestione

Il servizio di gestione di ACS attualmente espone una proprietà ID per ogni tipo di entità supportato, come descritto nell'articolo Guida di riferimento per l'API dei servizi di gestione ACS. Le proprietà ID vengono automaticamente impostate e gestite da ACS.

In questo aggiornamento del servizio, viene eseguita la migrazione di ACS a uno schema del database differente, e di conseguenza questi ID esposti tramite servizio di gestione cambieranno per tutti i tipi di entità.

Non è comune, e in genere non è consigliabile, che le applicazioni archivino o accettino una dipendenza hardcoded di questi ID allo scopo di eseguire query su entità specifiche tramite il servizio di gestione. È piuttosto consigliabile eseguire query sui tipi di entità RelyingParty, ServiceIdentity, RuleGroup e Issuer usando la proprietà Name, e su altri tipi di entità con un ID entità padre (ad esempio, RuleGroupId in caso di regole o IssuerId in caso di provider di identità).

Modifiche delle regole di confronto del database per l'elaborazione delle regole

Per espandere il supporto per le lingue internazionali e migliorare la sicurezza, questa versione di ACS aggiorna le regole di confronto sottostanti del database SQL usate per confrontare le attestazioni di input da SQL_Latin1_General_CP1_CI_AS a Latin1_General_100_BIN2. Questa modifica consente a ACS di supportare set di caratteri e combinazioni di set di caratteri aggiuntivi. Le applicazioni che si basano su attestazioni di input contenenti stringhe con più set di caratteri, non supportate da SQL_Latin1_General_CP1_CI_AS, potrebbero visualizzare attestazioni differenti o aggiuntive come risultato di queste nuove regole di confronto. I cliente che volessero sfruttare questa nuova possibilità sono invitati a convalidare le proprie applicazioni per la compatibilità con le nuove regole di confronto SQL.

Il 25 gennaio 2012, ACS 2.0 è stato aggiornato con le modifiche seguenti:

Nella versione precedente, ACS rispondeva con diversi codici errore quando un client si autenticava con un'autorità di certificazione inesistente (codice errore: ACS50026) o credenziali errate (codice errore: ACS50006). Questi codici errore venivano precedentemente prodotti quando un client provata ad autenticarsi con un nome dell'identità del servizio non valido oppure usando un token SWT o SAML rilasciato da un provider di identità non valido.

ACS restituirà i codici errore ACS50008, ACS50009 o ACS50012 per un'autenticazione non riuscita nei casi di SWT, SAML e nome utente/password, rispettivamente. Per altre informazioni, vedere la tabella riportata di seguito.

 

Risposta di autenticazione Prima Dopo

Autorità di certificazione inesistente

ACS50026 IssuerNotFound

ACS50008 InvalidSwt,

ACS50009 InvalidSaml OPPURE

ACS50012 AuthenticationFailed

Credenziali errate

ACS50006 InvalidSignature

Sempre nella versione precedente, ACS rispondeva con diversi codici errore OAuth 2.0 quando un client si autenticava con un'autorità di certificazione inesistente (invalid_client) o credenziali errate (invalid_grant). Anche questo comportamento è stato aggiornato e ACS restituirà un errore invalid_request quando la richiesta OAuth 2.0 non è corretta, invalid_client se l'autenticazione del client non riesce oppure l'asserzione fornita per l'autenticazione non è corretta o valida e invalid_grant se il codice di autorizzazione non è corretto o valido. Per altre informazioni, vedere la tabella riportata di seguito.

 

Risposta di autenticazione Esempi Prima Dopo

Autorità di certificazione inesistente

invalid_client

invalid_client

Credenziali errate

SWT viene firmato con una chiave errata. L'ID client e le credenziali non corrispondono a quelli configurati in ACS.

invalid_grant

Autenticazione non riuscita

Convalida dell'URI del gruppo di destinatari non riuscita. Convalida del certificato non riuscita. L'asserzione di un'identità del servizio contiene attestazioni autocertificate.

invalid_grant

Asserzione non corretta

Firma mancante dal token SWT. L'asserzione SAML non è un XML valido.

invalid_request

Codice di autorizzazione non corretto

invalid_grant

invalid_grant

Codice di autorizzazione non valido

invalid_grant

Richiesta OAuth2 non corretta

invalid_request

invalid_request

Le note sulla versione relative all'aggiornamento di luglio 2011 di ACS 2.0 contengono gli elementi seguenti:

Ogni Spazi dei nomi controllo di accesso riceve automaticamente l'aggiornamento del mese di luglio 2011, che non contiene alcuna modifica dei prerequisiti di ACS per i clienti nuovi o esistenti. Per altre informazioni sui prerequisiti di ACS correnti, vedere Prerequisiti di ACS.

L'aggiornamento del mese di luglio 2011 di ACS contiene le seguenti nuove funzionalità:

1. Le regole ora supportano fino a due attestazioni di input

Il motore regole ACS ora supporta un nuovo tipo di regola che consente di configurare due attestazioni di input anziché una sola. Le regole con due attestazioni di input possono essere usate per ridurre il numero complessivo di regole necessarie per eseguire funzioni di autorizzazione degli utenti complesse.

Nel portale di gestione ACS è possibile specificare una seconda attestazione di input in una nuova regola facendo clic su Add a second input claim nell'editor delle regole. Nel servizio di gestione, è possibile configurare due attestazioni di input con il tipo di entità ConditionalRule. È comunque possibile configurare le regole con una sola attestazione di input usando il tipo di entità Rule per la compatibilità con le versioni precedenti.

Per altre informazioni sulle regole con due attestazioni di input, vedere Gruppi di regole e regole.

2 Localizzazione in undici lingue

Il portale di gestione ACS e la pagina di accesso ospitata da ACS per applicazioni relying party ora supportano la localizzazione in undici lingue scritte, tra cui inglese, francese, tedesco, italiano, giapponese, coreano, russo, spagnolo, portoghese (Brasile), cinese semplificato e cinese tradizionale. È inoltre disponibile un'opzione "English (International)" che usa un formato di data alternativo per l'impostazione e la visualizzazione di date di validità e di scadenza per le chiavi. Per modificare la lingua scritta visualizzata per queste interfacce utente, è possibile usare uno dei tre metodi seguenti:

  • Menu di selezione della lingua: l portale di gestione ACS è possibile modificare rapidamente la lingua visualizzata usando un nuovo menu di selezione della lingua disponibile nell'angolo superiore destro.

  • URL: per modificare la lingua visualizzata nel portale di gestione ACS, è possibile aggiungere un parametro "lang" alla fine dell'URL di richiesta. I valori validi per questo parametro sono i codici ISO 639-1/3166 corrispondenti a una lingua supportata. Alcuni esempi sono en, de, es, fr, it, ja, ko, ru, pt-br, zh-cn e zh-tw. Di seguito è riportato un URL del portale di gestione ACS di esempio contenente un parametro che imposta il francese come lingua visualizzata:

    https://spaziodeinomi.accesscontrol.windows.net/?lang=fr

  • Preferenze del Web browser: se non si imposta una preferenza per la lingua tramite il parametro "lang" dell'URL oppure il menu di selezione della lingua, il portale di gestione ACS e le pagine di accesso ospitate da ACS determinano la lingua predefinita da visualizzare in base alle preferenze della lingua configurate nelle impostazioni del Web browser.

Di seguito sono riportate le modifiche rilevanti riguardanti il comportamento dei servizi in questa versione:

1. La codifica è ora UTF-8 per tutte le risposte di OAuth 2.0

Nella versione iniziale di ACS la codifica caratteri impostata per tutte le risposte HTTP dall'endpoint OAuth 2.0 è US-ASCII. Con l'aggiornamento del mese di luglio 2011, la codifica caratteri di tutte le risposte HTTP viene impostata su UTF-8 per supportare set di caratteri estesi.

Di seguito è riportato un problema noto di questa versione:

L'editor delle regola non può visualizzare le autorità emittenti personalizzate che non sono state associate ai provider di identità

Al momento, l'editor delle regole nel portale di gestione ACS può visualizzare solo le autorità emittenti dell'attestazione che sono associate a un provider di identità oppure ACS. Se viene caricata una regola che fa riferimento a un'autorità emittente che non corrisponde a nessuna di queste, verrà visualizzato l'errore seguente:

  • ACS80001: Questa regola è configurata per l'uso di un tipo di autorità di certificazione non supportato dal portale di gestione. Usare il servizio di gestione per visualizzare e modificare la regola.

Sono supportati due scenari in cui un'autorità emittente può esistere senza un provider di identità associato in ACS:

  • In uno scenario con delega di OAuth 2.0 nello Spazi dei nomi controllo di accesso viene creato mediante il servizio di gestione ACS un record dell'autorità emittente a cui non è associato un provider di identità.

  • Viene creata un'autorità emittente allo scopo di eseguire l'asserzione delle attestazioni in una richiesta di token su protocollo WRAP OAuth usando contemporaneamente un'identità del servizio con lo stesso nome per eseguire l'autenticazione con ACS.

A partire da questa versione, ACS non prevede limiti per il numero di provider di identità, applicazioni relying party, gruppi di regole, regole, identità del servizio, tipi di attestazione, record di delega, autorità emittenti, chiavi e indirizzi che è possibile creare per uno specifico spazio dei nomi Spazi dei nomi controllo di accesso.

Per altre informazioni sulle limitazioni del servizio, vedere Limitazioni del servizio ACS.

Aggiunte alla community

Mostra:
© 2015 Microsoft