I migliori plugin per un sito su piattaforma WordPress ?
7 settembre 2011 – 16:52 | Nessun commento

Ciao a tutti. Vorrei  aprire  una discussione sui migliori plugin che possono essere aggiunti ad un sito fatto con WordPress (dato che adoro questa piattforma). Ecco una lista dei miei preferiti… e voi cosa ne …

Leggi l'articolo completo »
Fotografia

Guide operative

Guide rapide e piccoli aiuti per mettere “in piedi” servizi, portali, server e tanto altro ancora…

Open Source

Tutti i software e i sistemi operativi open source. Trucchi, informazioni e news…

Sistemi Operativi

Sistemi Operativi Microsoft, da Windows XP a Windows 7… Trucchi, informazioni, novità e test…

Virtualizzazione

Programmi e sistemi di virtualizzazione

Home » Altri articoli in evidenza, Sistemi Operativi, Windows Server 2008

Active Directory Federation Services in Windows Server 2008 (parte2)

Scritto da – 6 febbraio 2010 – 18:57Nessun commento
Active Directory Federation Services in Windows Server 2008 (parte2)

IMPLEMENTAZIONE AD FS

Per implementare Active Directory  Federation Services, Federation Service Proxy e AD FS Web Agent, i seguenti requisiti di sistema operativo devono essere soddisfatti:

Active Directory  Federation Services e/o Federation Service Proxy:

 devono essere eseguiti su un server che Windows Server 2003 R2 Enterprise Edition, Windows Server 2003 R2 Datacenter Edition, Windows Server 2008 Enterprise Edition o Windows Server 2008 Datacenter Edition.
 

AD FS Web Agent :

deve essere eseguito su un server provvsto di qualsiasi versione di Windows Server 2003 R2 o Windows Server 2008.
Il client AD FS:

 deve essere eseguito su un computer che esegue Windows XP ,Windows Vista o Windows 7. 

 IIS, ASP.NET 2.0,. NET Framework 2.0, e un sito Web configurato con TLS / SSL:

  devono essere installati sul server a cui  è stato assegnato il ruolo di server federazione.

Opzioni per la configurazione di AD FS

È possibile utilizzare lo snap-in MMC AD FS in Windows Server 2008 per configurare il servizio federativo o  una server farm. È inoltre possibile utilizzare questo snap-in per la gestione della Trust Policy associata al tuo servizio federativo.

Per configurare il federation service dell’ account partner e quello del partner di risorsa, è necessario effettuare le seguenti operazioni:

Creare una TRUST POLICY tra i due partner. (Più avanti vedremo cosa sono).

Creare dei CLAIM per definire gli attributi dell’utente e  del gruppo necessari per l’autentica. (Più avanti diremo cosa sono).

Definire gli storage Active Directory o AD LDS contenenti gli account che richiedono l’autenticazione.

Creare e configurare le applicazioni in AD FS.

Cosa sono le Trust Policy?

Le trust policy si identificano con le configurazioni del rapporto di fiducia federativo instaurato tra i due partner dell’organizzazone. Includono alcuni settaggi importanti:

Token Lifetime. Questa impostazione definisce la durata di validità del token  SAML. Il valore predefinito è di 600 minuti o 10 ore. Il valore minimo è di un minuto.

 

Federation  Service URI. Questa impostazione consente di specificare una stringa case-sensitive che identifica univocamente un Federation Service. Questo URI identifica anche l’appartenenza ad una server farm di un  federation service.
 

Federation Service endpoint URL. Questa impostazione consente di specificare un unica location o  URL pubblica  che viene utilizzata per contattare tutti i server della Federazione in una server farm.

 

Use Windows trust relationship for this partner. Questa impostazione indica la relazione di fiducia da utilizzare quando è già implementato un forest  trust di Active Directory tra le organizzazioni.

 

Location for a certificate to verify the resource partner. Questa impostazione è utilizzata da un partner account per specificare la posizione del certificato che attesti la validità del partner di risorsa. Questa impostazione è disponibile solo per il partner account.

Cosa sono i Claim?

I claim sono le cosiddette “dichiarazioni” che riguardano gli utenti. Per intenderci sono come degli “Slogan” che identificano le proprietà di un utente e che vengono interpretati dai server federativi della parte account e della parte risorsa. Esistono 3 tipi di claim:

Identity Claim :

Include un User Principal Name (UPN) , un nome di posta elettronica, e un common name. C’è solo un claim di ogni tipo. Tuttavia, è possibile configurare ulteriori claim dello stesso tipo, come claim personalizzati. Se più di un tipo di Idenity Claim è presente in un token di protezione, la priorità è questa:

UPN (pippo@Italy.local)

Nome di posta elettronica (es. Pippo@Italy.it)

Common Name (Pippo Rossi)

Group Claim:

Definisce l’appartenenza di un account ad uno o più gruppi.

Custom Claim:

E’ un claim che può contenere informazioni personali dell’utente (es: numero di telefono).

Segue nella parte tre….

Lascia un commento!

Aggiungi il tuo commento qui sotto, oppure esegui un trackback dal tuo sito. Puoi anche iscriverti a questi commenti via RSS.

Sii gentile, rimani in argomento. Lo spam non sarà tollerato.

È possibile utilizzare questi tag:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Questo sito web supporta i Gravatar. Per ottenere il proprio globally-recognized-avatar, registra un account presso Gravatar.

CommentLuv badge