Foxserv

Introduzione

Una delle sfide chiave nella creazione di un’applicazione Web prevede la gestione dei diritti di accesso a tutte le varie funzioni che l’applicazione offre. In precedenza, era spesso sufficiente a distinguere tra gli ospiti, utenti e amministratori. Oggi, quando più persone all’interno di una società sono coinvolti in amministrare una applicazione web, si è reso necessario per controllare l’accesso alle diverse funzioni nel web app. Ciò è ancor più nel caso del mercato in rapida crescita di applicazioni intranet.
L’idea alla base di questo brusio applicazione web non è quello di creare versioni web-based di applicazioni legacy esistenti che sono altrettanto separati dal resto dell’infrastruttura IT come prima. La forza motrice è l’integrazione. I dati degli utenti la migrazione da un progetto all’altro è noioso e spesso non fattibile.Innovazione è in stallo. L’infrastruttura è riorganizzato, non per ragioni di efficienza, ma semplicemente a causa della necessità di alcune applicazioni. Il denaro viene sprecato, ed i progetti vengono ritardati. InserisciLiveUser.
LiveUser offre un sistema flessibile permesso e permette l’integrazione di fonti di autenticazione contemporaneamente. Tuttavia, invece di costringere tutte le sue funzionalità su ogni singolo utente, ne consegue un approccio flessibile contenitore per rendere le sue funzionalità veramente opzionale ed estensibile. LiveUser fornisce anche un ampio set di funzionalità out of the box – abbastanza per soddisfare la maggior parte dei requisiti più impegnativi che i clienti possono evocare. Può essere utilizzato per autenticare contro una vasta gamma di fonti di autenticazione, come XML, database, LDAP, RADIUS, IMAP e POP3. Il backend permesso sostiene i diritti degli utenti, gruppi di utenti, ruoli, proprietà, e molte altre caratteristiche che consentono di organizzare i vostri diritti.
LiveUser stessa è parte del repository PEAR, ed è mantenuto attivamente da più di una mezza dozzina di sviluppatori. Mentre la prima versione stabile è prevista per i prossimi mesi, è già in uso “in produzione” su molti siti web. Inoltre, LiveUser ha ormai raggiunto la fase di beta, il che significa che è il momento giusto per i potenziali utenti ad abbracciarla e assicurare che non si perde tempo su soluzioni personalizzate che semplicemente reinventare la ruota. In questo articolo vi introdurrà l’architettura di LiveUser, e la ‘out of the box’ LiveUser funzionalità che fornisce – sia per l’autenticazione e l’autorizzazione.

Architettura
Uno dei nostri principali decisioni architettoniche, realizzato durante le prime fasi di sviluppo LiveUser, era quello di separare il backend di autenticazione e l’autorizzazione per consentire l’integrazione delle diverse fonti di autenticazione in collaborazione con LiveUser. Ciò significa che, utilizzando LiveUser, ogni utente all’interno di ciascuna delle fonti di autenticazione dei dati può essere associato a un ID univoco all’interno del backend permesso. Allo stesso tempo, qualsiasi tipo di backend può essere integrato in LiveUser grazie al suo approccio contenitore. Così LiveUser può essere facilmente esteso alla gestione di altre fonti di dati o di integrare le funzionalità molto specifiche, a condizione che il backend dato implementa l’interfaccia fornita.
Abbiamo anche fatto una serie di disposizioni per assicurare le migliori prestazioni di runtime. Per uno, il codice necessario per gestire il contenuto all’interno delle fonti di dati è stato separato dal codice necessario includere durante le operazioni di runtime comune. Inoltre, le diverse caratteristiche nei contenitori autorizzazioni fornite sono state suddivise in diversi livelli di complessità: semplice, medio, complesso. Inoltre, grande cura è stata presa per garantire che nessuno dei livelli di complessità influenzare negativamente il permesso degli altri, mentre allo stesso tempo mantenendo la capacità di muoversi tra di loro in qualsiasi fase del progetto.
Un’altra parte del LiveUser che ha ottenuto un sacco di attenzione è l’API. L’idea di base era quella di minimizzare lo sforzo di formazione alle spalle LiveUser integrazione nelle applicazioni esistenti. Tutto ciò che serve è una decisione su come strutturare i diritti e di assegnazione dei diritti, dopo di che gli sviluppatori semplicemente bisogno di implementare il controllo dei diritti umani. E ‘abbastanza facile da porta gli schemi di autenticazione esistenti per LiveUser: schemi di autenticazione esistenti possono essere semplicemente avvolta in un contenitore.Per esempio, LiveUser fornisce un contenitore di autenticazione che avvolge PEAR:: Auth in LiveUser, rendendo la migrazione così banale come possibile, ma anche di esporre tutti i backend supportato da PEAR:: Auth a LiveUser.

Listato 1 mostra l’API di base chiamate che è necessario, per aggiungere LiveUser al codice. Se la chiamata al metodo scorso ha lasciato Vi state chiedendo, quindi leggere ulteriormente in questo articolo per ulteriori dettagli.

Lista 1: LiveUser – API di base chiamate/ / Carico LiveUser
require_once `LiveUser.php ‘;
/ / Crea un oggetto
$ LU = LiveUser:: factory (..);
/ / Utente loggato?
$ LU-> isLoggedIn ();
/ / Cos’è successo?
$ LU-> getStatus ();
/ / Assegno un diritto
$ LU-> checkRight ($ a destra);
/ / Assegno un diritto basato sulla proprietà
$ LU-> checkRightLevel ($ a destra, $ user, $ gruppo);
Alcuni usi campione del Admin API sono mostrato nel Listato 2. Per esempi di usi più dettagliate, consultare i numerosi esempi forniti come parte del pacchetto LiveUser, che si possono trovare anche nel CVS.

Lista 2: Usi Esempio di Admin API/ / Carico LiveUser Admin API
require_once `LiveUser / admin.php ‘;
/ / Crea un oggetto
$ Admin = new LiveUser_Admin (..);
/ / Aggiunge un utente
$ User_id = $ admin-> addUser (..);
/ / Chiama un metodo nel contenitore di autenticazione
$ Admin-> auth-> getUsers (..);
/ / Chiama un metodo nel contenitore permesso
$ Admin-> perm-> GetGroups (..);
A questo punto si consiglia inoltre di richiedere un certo tempo per sfogliare il codice e familiarizzare con l’architettura. Si noti che tutti i file common.php sono in realtà definizioni di interfaccia per i contenitori dato.Autenticazione
LiveUser attualmente fornito con cinque contenitori diversi per l’autenticazione. Tre di loro si differenziano dallo strato di astrazione del database utilizzato: PEAR:: DB, PEAR:: MDB, e PEAR:: MDB2. Gli altri due sono un contenitore basato su XML e un contenitore wrapper PEAR:: Auth. Funzionalità mancanti possono essere aggiunti estendendo un contenitore esistente o scrivendo un nuovo contenitore (estendendo il relativo file di interfaccia).
Dal LiveUser può accettare un’istanza esistente di uno dei tre livelli di astrazione (detto in precedenza), tra cui tre diverse varianti del contenitore del database interno LiveUser in grado di migliorare notevolmente le prestazioni. Si consiglia di utilizzare i contenitori a base MDB, per la massima compatibilità con i più esotici RDBMS, dal momento che MDB offre un insieme più completo di funzioni astrazione. Un’altra caratteristica interessante del contenitore del database è che sia il nome della tabella e le colonne della tabella utilizzati sono configurabili – così, per la maggior parte delle applicazioni esistenti, i contenitori database può essere utilizzato senza dover modificare lo schema esistente.Permesso
La parte permesso di LiveUser richiede una spiegazione un po ‘di più rispetto alla sezione di autenticazione. Come accennato prima, LiveUser divide la funzionalità per la parte permesso in tre livelli: semplice , medio e complesso . Al momento della scrittura, LiveUser fornisce un’implementazione di tutti i livelli di complessità utilizzando un database backend, e l’attuazione del semplice contenitore usando un backend XML. Il backend database viene implementato utilizzando i tre livelli di astrazione; PEAR:: DB, PEAR:: MDB, e PEAR:: MDB2. Tutti i commenti relativi valgono anche per i contenitori permesso. Tuttavia, i contenitori permesso solo permettono di impostare un prefisso facoltativo tavolo, invece di consentire la configurazione di tutti i nomi di tabella e colonna.
La realizzazione dei tre diversi livelli di complessità servire come un buon esempio di come si possa va espandendo su un container esistente, sia in permesso e la parte di autenticazione LiveUser. Ogni livello di complessità eredita dal livello di sotto di essa – che è, il contenitore di media eredita la sua funzionalità dal semplice contenitore, mentre il contenitore complesso eredita la sua funzionalmente dal contenitore mezzo.
Successivamente, lavoreremo attraverso ciascuno dei contenitori a partire dal semplice al complesso del contenitore. Sarebbe bene fare riferimento allo schema del database, mentre leggete le sezioni prossima nell’articolo.
Si prega di notare che la tabella liveuser_right_scope non è attualmente in uso in LiveUser. Uno dei suoi scopi originale era quello di consentire a un altro livello di organizzazione dei diritti. Per esempio, se il perm_type nella tabella liveuser_perm_users era sotto di due, sarebbe stato possibile mostrare solo i diritti per gli utenti in una GUI di amministrazione. Tuttavia, questa funzione non ha trovato la sua strada nel codice ma, né vi è alcun piano attuale per aggiungerlo nel pacchetto.Permessi semplice
Come suggerisce il nome questo contenitore fornisce solo la semplice autorizzazione: l’assegnazione di diritti agli utenti. Tuttavia, poiché è nel punto più basso della struttura di ereditarietà, è importante avere familiarità con alcuni dei bisogni fondamentali LiveUser tabelle:

• La tabella più importante è la tabella liveuser_perm_users. Agli utenti di tutti i contenitori di autenticazione sono associati a un perm_user_id singolo, in questa tabella. Poiché questo ID agisce come un identificatore univoco per un determinato utente, dovrebbe essere utilizzato come punto di riferimento per ogni utente al di fuori di LiveUser. Il campo perm_type definisce il tipo di utente. Per la semplice contenitore impostare il valore su quattro (o superiore) se si desidera che l’utente sia un super amministratore che ha automaticamente tutti i diritti. I diversi livelli sono definiti come costanti all’interno del file di classe permesso di interfaccia.
• Tutti i diritti sono definiti nella tabella liveuser_rights e sono raggruppati in aree cosiddette utilizzando la tabella liveuser_areas, mentre le aree sono a loro volta organizzati in applicazioni utilizzando la tabella liveuser_applications. Diritti di organizzare in questo modo ha diversi vantaggi. In primo luogo, questo rende possibile la scrittura di uno script che esporta un array o di una serie di costanti – questo significa che è possibile utilizzare nomi per i diritti all’interno dell’applicazione invece di interi che rappresenta l’ID giusto. In secondo luogo, queste informazioni possono anche essere usato per migliorare la struttura dei diritti all’interno di una GUI di amministrazione. Infine, si rende possibile un ulteriore elemento – un esempio dell’uso di questo è fatto nel contenitore di media. Gli utenti vengono assegnati i loro diritti nella tabella liveuser_userrights.
• Le tabelle liveuser_language e liveuser_translations vengono utilizzati per aggiungere un nome e una descrizione di applicazioni, le aree, i gruppi (che sarà introdotto nel contenitore di media), lingue e diritti. Il section_id nella tabella liveuser_translations corrisponde all’ID del soggetto (ad esempio, il area_id) che viene descritto. section_type è un intero che viene assegnato per tutti i tipi di entità che può essere descritto nella tabella.

Un insieme di costanti che rappresentano i diversi tipi si possono trovare all’interno della classe interfaccia per le autorizzazioni della API di amministrazione.Permessi di media
Mentre la funzionalità del semplice contenitore può essere sufficiente per la maggior parte dei siti web, diventa molto limitante per le applicazioni Web reali. Per questo motivo, il contenitore di media introduce due concetti chiave: i gruppi e gli amministratori dell’area .
In LiveUser, gruppi di utenti e ruoli sono in realtà memorizzati e manipolati allo stesso modo. Si noti che la prossima major release di LiveUser permetterà ai due di essere separati, pur mantenendo la possibilità di miscelare i due concetti come e quando necessario. Per questa ragione, la corrente liveuser_groups tavolo sarà esteso a definire facoltativamente una group_type . Gli utenti vengono assegnati a un gruppo utilizzando la liveuser_groupusers tavolo, e la liveuser_grouprights tabella viene utilizzata per assegnare i diritti a un gruppo.
La “zona amministratori” sfrutta la caratteristica organizzazione per i diritti che abbiamo acquisito attraverso la tabella liveuser_area . Se un utente è stato impostato il perm_type admin zona (all’interno del liveuser_perm_users tabella) utilizzando il numero intero ‘tre’, uno sguardo al liveuser_area_admin_areas tabella è fatto durante il processo di lettura i diritti. Un utente che è stato assegnato aree nella tabella viene automaticamente concesso tutti i diritti della data area, rendendo così molto facile da concedere a un utente la gestione dei diritti ad una certa sezione del proprio sito, senza dover assegnare manualmente alcun diritto di recente introduzione.Permessi complesso
La maggior parte delle applicazioni Web dovrebbero essere ben coperti con le funzionalità fornite dal contenitore mezzo. Alcuni hanno bisogno di andare un passo avanti, comunque. Il contenitore complesso introduce i seguenti concetti nuovi:sottogruppi , eredità a destra , e giusti livelli .
La liveuser_subgroup tabella può essere utilizzata per organizzare gruppi in strutture infinitamente profonda. Si noti ancora che il concetto di “gruppo” in LiveUser copre sia “gruppi di utenti” e “ruoli”. Una funzionalità simile è disponibile anche per i diritti con il has_implied campo nella liveuser_rights tabella, in combinazione con il liveuser_right_implied tavolo. Se i campi has_implied contengono Y, LiveUser farà una ricerca nel liveuser_right_implied tabella per determinare quali ‘diritti’ il diritto dato implica. Questo può essere utile per garantire che tutti gli utenti che hanno il diritto di ‘cancellare’ un dato oggetto anche il diritto di ‘leggere’ sullo stesso oggetto. Il “diritto eredità” concetto assicura che non è necessario assegnare esplicitamente il diritto ‘leggere’ per l’utente, se l’eredità è impostato come descritto. (Questo significa anche che l’utente perde il diritto di leggere immediatamente quando non ha più il diritto di cancellare.)
Il concetto di “livelli di destra” è un’altra caratteristica LiveUser potente. Questo concetto permette di limitare l’applicazione di un diritto al concetto di proprietà. Per esempio, è possibile limitare gli utenti a ‘modificare’ solo ciò che in origine ‘aggiunto’ al sistema. Si noti che la memorizzazione della proprietà deve essere affidati a terzi di LiveUser. Il “diritto livelli” concetto permette anche di passare proprietari LiveUser contemporaneamente e gestire sia gli utenti e / o gruppi come proprietari. Un esempio di API chiamata utilizzando il concetto di proprietà è indicato nella riga del listato 1.
LiveUser definisce tre livelli, da uno a tre, l’ultimo che è il più alto livello. Tutti i livelli più elevati sono il livello più basso. Un diritto concesso a significa ‘un livello’ che il diritto può essere applicato solo se la perm_user_id dell’utente autenticato corrisponde a uno degli ID passato come i proprietari degli utenti. Che attribuisce il diritto a ‘livello due’ permette anche di applicare il diritto, se uno dei gruppi, l’utente autenticato è un membro, è elencato nel gruppo di proprietari. Con ‘terzo livello’ il diritto può essere applicato senza limitazioni. Il livello a cui viene concesso un diritto dato è determinato dalla right_level campo nella liveuser_userrights eliveuser_grourights tabelle. Speciali tipi di amministratore come admin area o super amministratore sono sempre concesso un ‘livello tre’ a destra.
Si noti che LiveUser cerca di determinare il livello più alto in cui un utente ha effettuato il diritto indipendentemente dal fatto che questo è stato ottenuto tramite assegnazione diretta per l’utente, o attraverso un gruppo. L’unica eccezione a questa regola è che il livello della liveuser_userrights tabella può opzionalmente essere un valore negativo. Nel caso un ‘livello negativo’ è assegnato, il livello viene sottratto dal livello utente potrebbe avere acquisito tramite l’appartenenza a un gruppo. Solo se il livello risultante è sopra lo zero sarà l’utente ha diritto a livello determinato dalla sottrazione. Pertanto, se un utente ha diritto a ‘livello meno due’, e lei è un membro di un gruppo che ha lo stesso diritto al ‘livello tre’, avrebbe in realtà finiscono per avere il diritto di ‘primo livello’. Questa caratteristica non è probabilmente qualcosa che viene utilizzata spesso, ma può evitare di dover creare un nuovo ruolo proprio per disabilitare un diritto specifico che un utente ottiene attraverso un ruolo.Nomi diversi, lo stesso concetto
Una delle sfide di integrare un sistema come LiveUser, in base alle esigenze del cliente, sia effettivamente in grado di mappare i termini utilizzati dal cliente per i concetti e termini utilizzati nella LiveUser. Per esempio, in LiveUser, il “permesso” è usato al posto di “autorizzazione” – questo è stato fatto in quanto l’autorizzazione è spesso confusa con l’autenticazione, due cose nettamente diverse. Si noti inoltre che il ruolo parola non compare nelle versioni correnti, perché i ruoli sono effettivamente implementate utilizzando i gruppi (in LiveUser). Con le spiegazioni in questo articolo, si sarà in grado di mappare i concetti in modo corretto.
Un concetto che si può spesso essere di fronte è RBAC. Essenzialmente, RBAC fornisce i seguenti concetti al fine di gestire la gestione dei diritti: utenti , ruoli ,permessi , oggetti e operazioni . Per esempio, una domanda che si potrebbe desiderare di chiedere in un sistema RBAC potrebbe andare così: Esiste un dato utente ha un determinato ruolo che gli concede un permesso di eseguire una determinata operazione su un dato oggetto. Al primo sguardo non sembra LiveUser può effettivamente essere visto come una implementazione RBAC. Tuttavia, se si passa attraverso di loro, passo dopo passo, è possibile vedere i concetti corrispondenti in LiveUser.
LiveUser ha un concetto di utenti e ruoli. Un diritto che è stato concesso ad un utente è semplicemente un permesso. I prossimi due concetti non potrebbe essere così ovvia – essenzialmente, in RBAC, trovando il diritto di controllare, si compone di due pezzi di informazione – l’oggetto e l’operazione. Un oggetto è solo una risorsa di sistema che è soggetto a qualche forma di controllo degli accessi. Quindi abbiamo solo bisogno di un modo per determinare il controllo degli accessi, che sarà controllato prima di un’operazione è permesso di essere eseguiti. Per questo stesso motivo, l’operazione è solo un diritto. Essere in grado di determinare il diritto di controllare, quando si accede a un oggetto, può essere fatta sia da avere una mappatura chiara tra i diversi tipi a disposizione di oggetti e di una data area, oppure memorizzando destra lungo con l’oggetto reale.
C’è un filo su SitePoint che funge da punto di ingresso del bene a coloro che non sono a conoscenza di RBAC.Il cammino da seguire
Come indicato in premessa, una prima versione stabile è prevista in un futuro vicino. Il numero di bug riscontrati in questi ultimi mesi sono stati molto modesti.Tuttavia, ci sono una serie di caratteristiche che devono essere lavorato fino ad allora. La maggior parte del lavoro è stato fatto sulle API per rendere più facile da usare e più flessibile e intuitivo.
Alcune delle caratteristiche prese in considerazione sono la possibilità di scelta dei gruppi separati in gruppi di utenti e ruoli, eliminando la dipendenza da sessioni di PHP, e la possibilità di autenticarsi nei confronti delle altre fonti di dati come NTLM e Kerberos. Un’altra caratteristica attualmente in discussione è la capacità di impostare e richiedono una certa qualità di autenticazione. Mentre l’autenticazione debole può essere sufficiente per alcune parti di un’applicazione, altri possono richiedere l’autenticazione particolarmente forte. Dovrebbe essere possibile per l’autenticazione di richiedere una certa qualità di autenticazione. Se l’utente è già autenticati con una qualità inferiore, LiveUser dovrebbe costringere gli utenti ad autenticarsi contro una fonte di qualità superiore di autenticazione prima di poter continuare. Il livello di qualità rilevanti possono essere configurate per ogni fonte di dati di autenticazione. Per esempio, l’autenticazione contro una base di dati può portare a ‘livello due’ di qualità e contro un altro sarebbe risultato in un ‘livello di quattro’.
Un altro importante miglioramento è stato progettato nel settore dei diritti di caching. LiveUser cerca di ottimizzare le prestazioni di runtime mettendo in cache i diritti di un utente ha dato. Sia il contenitore e il contenitore complesso medio (in una certa misura) esigono che una serie di operazioni da fare per determinare i diritti di un determinato utente. Al momento, però, LiveUser fornisce solo la possibilità di memorizzare nella cache i diritti all’interno della sessione utente. I limiti strutturali all’interno di LiveUser, che in precedenza reso questo un requisito, sono stati già rimossi. Quindi è probabile che LiveUser presto acquisire la capacità di cache di fuori della sessione. Ciò significa anche che i cambiamenti dell’utente nel autorizzazioni utente influenzerà le sessioni utente attivo, che attualmente non è il caso.
Un’altra area che verrà esplorato in modo più approfondito nei prossimi mesi è il concetto di Single Sign-On (SSO). In realtà tutto ciò che probabilmente ha bisogno di essere fatto è quello di fornire un campione di alcuni contenitori di attuazione diverse varianti di Single Sign-on – l’infrastruttura fornita da LiveUser sembra essere più che sufficiente.Conclusione
LiveUser è un framework molto flessibile che può essere utilizzato per gestire l’autenticazione e le autorizzazioni. Esso è destinato in scala con le esigenze dell’applicazione. Una facile integrazione nei infrastruttura IT esistente, che è spesso pieno di applicazioni legacy, è anche uno dei momenti salienti del LiveUser.A causa della netta separazione delle parti di autenticazione e l’autorizzazione e l’approccio contenitore di LiveUser, potrebbe non essere l’attuazione più rapida possibile del set di funzionalità fornite. Tuttavia, molto lavoro è già stato fatto per renderlo sufficientemente veloce per la maggior parte delle applicazioni.
Una delle aree in cui LiveUser manca attualmente è la documentazione. Questo articolo è in realtà l’introduzione più completa a LiveUser disponibile ovunque in questo momento. Il team di sviluppo LiveUser è comunque lavorando per porre rimedio a questa situazione con l’aiuto di un bacino d’utenza sempre più grande, e un Wiki è stata creata per facilitare la collaborazione. Una volta che la prima versione stabile rotola fuori, LiveUser sarà (si spera) essere pienamente documentato e pronto per essere utilizzato in una grande varietà di applicazioni.< i > Chi l’Autore < / i >
Lukas Smith è un membro del Gruppo PEAR e principale sviluppatore di MDB, MDB2 e LiveUser. Egli è anche uno dei co-fondatori di BackendMedia, specializzata nello sviluppo di applicazioni Web e servizi connessi a Internet.Link e Letteratura

• pear.php.net / pacchetto / LiveUser
• cvs.php.net / cvs.php / pera / Perm_LiveUser / docs / examples /
• pear.php.net / pacchetto / DB
• pear.php.net / pacchetto / MDB
• pear.php.net/package/MDB2
• www.backendmedia.com / LiveUser / liveuser_db_schema.png
• cvs.php.net / cvs.php / pera / Perm_LiveUser / scripts / DefineGenerator
• www.sitepoint.com/forums/showthread.php?t=162027&highlight=rbac
• pear.limbourg.com