Note sulla versione

Aggiornamento: 19 giugno 2015

Si applica a: Azure

Questo argomento descrive le nuove funzionalità in ogni versione di Microsoft Azure Active Directory Controllo di accesso (noto anche come servizio Controllo di accesso o ACS), spiega come ogni versione del prodotto differisce dai relativi predecessori e evidenzia eventuali modifiche di rilievo che potrebbero influire sul codice scritto per una versione precedente.

• Marzo 2015 - Migrazione degli spazi dei nomi ACS a OpenID Connect di Google

• Giugno 2014 - Supporto per il provider di identità Google

• Note sulla versione dell'aggiornamento di luglio 2013

• Note sulla versione dell'aggiornamento di dicembre 2012

• Note sulla versione dell'aggiornamento di settembre 2012

• Note sulla versione dell'aggiornamento di giugno 2012

• Note sulla versione dell'aggiornamento di maggio 2012

• Note sulla versione dell'aggiornamento di gennaio 2012

• Note sulla versione di luglio 2011

Marzo 2015 - Migrazione degli spazi dei nomi ACS a OpenID Connect di Google

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 indicazioni dettagliate, vedere Migrazione degli spazi dei nomi ACS a Google OpenID Connessione.

Giugno 2014 - Supporto per il provider di identità 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 usati da Google continueranno a funzionare fino al 20 aprile 2015. Se l'applicazione richiede il supporto per gli account Google, è consigliabile registrare direttamente l'applicazione.

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.

Note sulla versione dell'aggiornamento di luglio 2013

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 ACS.

Note sulla versione dell'aggiornamento di dicembre 2012

Nuove funzionalità

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

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

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

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

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

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

Per altre informazioni, vedere Esempio di codice: ASP.NET MVC 4 con l'accesso federato e l'autenticazione passiva per ASP.NET in 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 a spazi dei nomi Controllo di accesso nel nuovo portale di gestione di Azure

Il nuovo portale di gestione di Azure (https://manage.WindowsAzure.com) include una route al portale di gestione ACS familiare in cui si creano e gestiscono gli spazi dei nomi Controllo di accesso.

Per passare al portale di gestione ACS:

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

2. Fare clic su uno spazio dei nomi Controllo di accesso e quindi 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 spazio dei nomi Controllo di accesso per un bus di servizio

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

Per configurare e gestire lo spazio 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 spazio dei nomi Controllo di accesso sia associato al bus di servizio, vedere il campo Spazio dei nomi dei servizi nella parte superiore della pagina del servizio 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 Controllo di accesso per un 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. È inoltre possibile aggiornare i certificati usando la casella di controllo Reimport data from WS-Federation metadata URL upon save.

• 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 per copiarlo in un'applicazione, è ora necessario premere il pulsante Show Password o Show Key.

Possibilità di federate directory tenant con spazi dei nomi Controllo di accesso

Azure Active Directory tenant possono ora essere usati come provider di identità negli spazi dei nomi Controllo di accesso. In questo modo, molti scenari, ad esempio l'abilitazione dell'applicazione Web, accettano sia identità organizzative da tenant directory che identità consumer da provider di social network, ad esempio Facebook, Google, Yahoo!, Account Microsoft o qualsiasi altro provider OpenID. È possibile trovare istruzioni dettagliate su come implementare lo scenario in questo post, effettuare il provisioning di un tenant 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 altre informazioni, vedereDeveloper Preview: SAMLProtocol.

Problemi noti

Nell'aggiornamento di dicembre 2012 Microsoft Azure Active Directory Controllo di accesso (noto anche come Controllo di accesso Service o ACS), sono stati identificati i seguenti problemi noti:

Azure Co-Administrators può ora gestire spazi dei nomi Controllo di accesso. Tuttavia, è necessaria un'azione per propagare coamministratori preesistenti a uno spazio dei nomi Controllo di accesso preesistente.

Prima dell'aggiornamento di novembre 2012, è stato risolto un problema in cui, per impostazione predefinita, solo l'amministratore del servizio di Azure primario poteva gestire Controllo di accesso spazi dei nomi creati nella sottoscrizione. Se un coamministratore di Azure ha tentato di accedere al portale di gestione di ACS per uno spazio dei nomi Controllo di accesso, riceverà uno dei codici di errore ACS seguenti:

• ACS50000: si è verificato un errore che emette un token.

• ACS60000: si è verificato un errore durante l'elaborazione delle regole per la relying party usando l'autorità di certificazione 'uri:WindowsLiveID'

• ACS60001: nessuna attestazione di output è stata generata durante l'elaborazione delle regole.

Questo problema viene ora risolto per i nuovi spazi dei nomi Controllo di accesso creati da qualsiasi amministratore del servizio di Azure o coamministratore. 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 alla portale di Azure (https://windows.azure.com/) usando le credenziali dell'amministratore del servizio o dell'amministratore dell'account.

2. Rimuovere e riaggiungere il coamministratore usando le indicazioni riportate in Come aggiungere e rimuovere Co-Administrators per le sottoscrizioni di Azure (https://msdn.microsoft.com/library/windowsazure/gg456328.aspx)

3. Uscire e accedere al portale di Azure usando le credenziali del coamministratore. Sarà quindi possibile gestire gli spazi dei nomi Controllo di accesso.

Note sulla versione dell'aggiornamento di settembre 2012

Nel settembre 2012, Microsoft Azure Active Directory Controllo di accesso (noto anche come servizio Controllo di accesso o ACS) ha ricevuto un aggiornamento che contiene 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 pubblicati dagli spazi dei nomi Controllo di accesso è sempre minuscolo. Nelle versioni precedenti, venivano usate le maiuscole/minuscole immesse alla creazione dello spazio dei nomi nel portale di Azure. L'attributo "entityID" identifica lo spazio dei nomi Controllo di accesso per le applicazioni di relying party e di seguito è riportato un esempio dell'attributo:

<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 è stata necessaria per risolvere potenziali problemi di convalida dei token in cui il caso lettera dello spazio dei nomi Controllo di accesso nel token emesso da ACS (che è sempre in minuscolo) non corrisponde alla lettera-case dello spazio 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 spazio dei nomi Controllo di accesso tramite il portale di gestione o il servizio di gestione ACS sono ora necessari per avere una dimensione di chiave pubblica non superiore a 4096 bit. Ciò include i certificati usati per la firma, la crittografia e la decrittografia dei token.

In Windows la dimensione della chiave pubblica di un certificato può essere verificata aprendo il file del certificato (.CER), selezionando la scheda dei dettagli e controllando il valore del campo relativo alla 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.

Modifica secondaria apportata all'algoritmo di selezione della chiave primaria usato quando ACS firma un token mediante un certificato X.509

Nel portale di gestione ACS e nel servizio di gestione è disponibile un campo Make Primary relativo ai certificati per la firma di token che, se selezionato, implica che ACS firmi i token usando tali certificati. Con questa versione, se non sono presenti certificati di firma del token configurati con il campo "Rendi primario", lo spazio dei nomi Controllo di accesso userà il certificato di firma del token non primario esistente con la data di inizio più recente 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: modifica del comportamento di firma quando si usa un 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 spazio dei nomi Controllo di accesso

• Certificato di firma X.509 assegnato allo spazio 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 spazio dei nomi Controllo di accesso

Note sulla versione dell'aggiornamento di giugno 2012

Nel giugno 2012 ACS ha ricevuto un aggiornamento che conteneva la nuova funzionalità seguente:

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

Questo aggiornamento introduce il supporto per il formato JSON Web Token (JWT) BETA in ACS. JWT è un formato di token con codifica JSON leggero che può essere firmato usando un certificato X.509 o una chiave simmetrica e può essere rilasciato da ACS per affidarsi 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 è configurabile anche tramite il servizio di gestione ACS.

Per altre informazioni sul formato del token JWT, vedere la specifica del token WEB JSON. In futuro verranno presentati esempi di codice ACS che includono i token JWT.

Note sulla versione dell'aggiornamento di maggio 2012

All'inizio di maggio 2012 ACS ha ricevuto un aggiornamento che conteneva la modifica seguente:

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

Il servizio di gestione ACS espone attualmente una proprietà ID per ognuno dei tipi di entità supportati, come descritto in Informazioni di riferimento sulle API del servizio di gestione ACS. Queste proprietà ID vengono impostate e gestite automaticamente da ACS.

In questo aggiornamento del servizio viene eseguita la migrazione di ACS a uno schema di database diverso e, di conseguenza, questi ID esposti tramite il 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 del database SQL sottostanti 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 aggiuntivi di set di caratteri. 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.

Note sulla versione dell'aggiornamento di gennaio 2012

Il 25 gennaio 2012 ACS 2.0 ha ricevuto un aggiornamento che conteneva le modifiche seguenti:

• Modifica delle risposte di errore di ACS per le richieste di autenticazione non riuscite

• Modifica dei codici errore OAuth 2.0 per le richieste di autenticazione non riuscite

Modifica delle risposte di errore di ACS per le richieste di autenticazione non riuscite

Nella versione precedente ACS ha risposto con codici di errore diversi quando un client ha eseguito l'autenticazione con un'autorità emittente inesistente (codice errore: ACS50026) o credenziali non corrette (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 di errore ACS50008, ACS50009 o ACS50012 per un'autenticazione non riuscita nei casi rispettivamente di SWT, SAML e nome utente/password. Per altre informazioni, vedere la tabella riportata di seguito.

Modifica dei codici errore OAuth 2.0 per le richieste di autenticazione non riuscite

Anche nella versione precedente ACS ha risposto con codici di errore OAuth 2.0 diversi quando un client ha eseguito l'autenticazione con un'autorità di certificazione inesistente (invalid_client) o credenziali non corrette (invalid_grant). Questo comportamento è stato aggiornato e ACS restituirà invalid_request quando la richiesta OAuth 2.0 è in formato non valido, invalid_client se il client non riesce l'autenticazione o l'asserzione fornita per l'autenticazione non è valida o non è valida e invalid_grant se il codice di autorizzazione è in formato non valido o non valido. Per altre informazioni, vedere la tabella riportata di seguito.

Note sulla versione di aggiornamento di luglio 2011

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

• Prerequisiti

• Nuove funzioni e caratteristiche

• Modifiche

• Problemi noti

• Problemi noti

Prerequisiti

Tutti gli spazi dei nomi Controllo di accesso ricevono automaticamente l'aggiornamento di luglio 2011. Questo aggiornamento non contiene modifiche ai prerequisiti di ACS per i clienti nuovi o esistenti. Per altre informazioni sui prerequisiti di ACS correnti, vedere Prerequisiti di ACS.

Nuove funzioni e caratteristiche

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

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

Il motore regole ACS supporta ora un nuovo tipo di regola che consente di configurare fino a due attestazioni di input, anziché una sola attestazione di input. 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 di ACS è possibile specificare una seconda attestazione di input in una nuova regola facendo clic su Aggiungi una seconda attestazione di input 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 le applicazioni di relying party supportano ora 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:

• Selettore della lingua: nel portale di gestione di ACS è possibile modificare immediatamente la lingua visualizzata usando un nuovo menu selettore di lingua visualizzato nell'angolo in alto a destra del portale.

• URL : la lingua visualizzata nel portale di gestione di ACS può essere modificata aggiungendo un parametro "lang" alla fine dell'URL della 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 esempio di URL del portale di gestione di ACS con un parametro che imposta la lingua visualizzata su francese:

  https://your-namespace.accesscontrol.windows.net/?lang=fr

• Preferenze del Web Browser : se il parametro url "lang" o il selettore di lingua non è mai stato usato per impostare una preferenza di lingua, le pagine di accesso ospitate da ACS e ACS determinano la lingua predefinita da visualizzare in base alle preferenze di lingua impostate nelle impostazioni del Web browser.

Modifiche

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 dei caratteri impostata per tutte le risposte HTTP dall'endpoint OAuth 2.0 era 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.

Problemi noti

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à

Attualmente, l'editor di regole nel portale di gestione di ACS può visualizzare solo gli emittenti di attestazioni associati a un provider di identità o 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 usare un tipo di autorità di certificazione attestazione non supportato dal portale di gestione. Usare il servizio di gestione per visualizzare e modificare la regola.

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

• In uno scenario di delega OAuth 2.0 viene creato un record emittente nello spazio dei nomi Controllo di accesso usando il servizio di gestione ACS e l'autorità emittente non ha un provider di identità associato.

• Quando un'autorità emittente viene creata allo scopo di affermare le attestazioni in una richiesta di token nel protocollo OAuth WRAPPING, usando un'identità del servizio identicamente denominata per l'autenticazione con ACS.

Quote

A partire da questa versione, ACS non impone limiti al numero di provider di identità, applicazioni di relying party, gruppi di regole, regole, identità del servizio, tipi di attestazione, record di delega, autorità di certificazione, chiavi e indirizzi che possono essere creati per un determinato spazio dei nomi Controllo di accesso.

Limitazioni del servizio

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