C'è un motivo per cui gli sviluppatori di software non sono esternalizzazione autorizzazione?

Question

La proposta di valore di esternalizzazione dell'identità sta iniziando ad aumentare in cui molti siti ora accettano OpenID, CardSpace o identità federate. Tuttavia, molti sviluppatori non hanno ancora preso il passo successivo di esternare approcci autorizzazione e l'uso sulla base di XACML.

E 'la ragione per la mancanza di consapevolezza o qualcos'altro? Come ci si aspetta di conoscere XACML approcci basati per lo sviluppo del software?

Si prega di notare che io sto chiedendo circa l'autorizzazione, non l'autenticazione.

Answer 1

Credo che la prospettiva di autorizzazione esternalizzazione è una cosa molto più difficile che esternalizzare l'autenticazione (OpenID, CardSpace, etc.). Ciò è dovuto principalmente al fatto che l'autorizzazione è molto più specifica applicazione. Ciò che una persona è autorizzato a fare nella mia domanda non può essere in grado di fare nella vostra applicazione, e questo è anche supponendo c'è qualche Parrallel comune tra la mia domanda e il tuo di, che molto probabilmente non ci sarà.

Non voglio dire che la esternalizzazione autorizzazione sarà non essere fatto, ma onestamente un tempo difficile venire con ragioni per le quali ci si vuole veramente farlo. Forse per una suite di applicazioni che funzionano fianco a fianco, ma ancora una volta, che molto probabilmente essere sostenuta internamente, piuttosto che all'esterno.

Answer 2

Inoltre, ricorda che l'autorizzazione! == autenticazione. Solo perché un utente è autenticato non significa aver risolto la parte di autorizzazione del sito. Hai ancora bisogno di stabilire chi può fare cosa e quando.

Answer 3

Il motivo principale che continuiamo a rotolare la nostra è che le opzioni come OpenID ed altri sono apparentemente supportati solo da siti tech. Siamo un giocatore più piccolo, in modo da non iniziare a utilizzare un provider esterno fino al momento che v'è una maggiore accettazione degli utenti.

Non vogliamo che la prima cosa che un utente deve fare sul nostro sito di coinvolgere andare in un altro sito.

Answer 4

Mi sembra di essere caduto nella equivoco che gli altri hanno - la questione era di circa di autorizzazione esterno. Personalmente, mi fiderei distribuito solo l'autorizzazione su una rete locale in cui ho il controllo sui server di autenticazione e autorizzazione. Non avrei mai usare autorizzazione esterno su un sito web.

Qui di seguito sono i miei commenti su OpenID come un servizio di autenticazione.

1) Come è stato sottolineato, l'autorizzazione! = Autenticazione. OpenID gestisce l'autenticazione, ma il proprietario web app ha ancora il pieno controllo dei diritti assegnati a tale accesso. Questo è positivo, ma la confusione di questo è negativo.

2) non riesco a trovare il link, ma OpenID è aperto a ingegneria sociale / principale al centro / attacchi di phishing. I fornitori cercano di evitare questo (immagini d'identità, certificati browser, chiamata indietro di verifica, ecc) ma non aiuta quando il sito cappello nero si apre una finestra di dialogo / pagina che dice "inserire il proprio nome utente e la password OpenID" e il genio utente risponde.

3) Ogni fornitore di un ID federata ha la capacità (e qualcuno direbbe la responsabilità) per tenere traccia di tutte le attività dei loro utenti, indipendentemente da quale sito che utilizzano l'ID per. Questo è il motivo per cui Google e Yahoo sono entusiasta di fornire ID federati, ma non così entusiasta di consumando di loro.

4) Contrariamente a un commento di cui sopra, è comunemente il caso che usando OpenID riduce la barriera di registrazione, soprattutto quando un utile interfaccia utente fa notare che un nuovo utente ha probabilmente già un OpenID. Questo è ancora più vero quando si utilizza una soluzione combinata OpenID / OAuth come RPX.

Quindi, dal mio punto di vista, i rischi di usare OpenID sono sull'utente, non il sito web. Non posso impedire all'utente di essere phishing, facendo loro provare a ricordare ancora un altro ID utente e la password. Inoltre, cappelli neri non hanno bisogno di fare qualcosa di più nefasto di memorizzare le password degli utenti per il loro sito in formato testo per ottenere l'accesso ad altri account di un utente. Quante persone utilizzare una password diversa per ogni sito web log in?

Answer 5

La maggior parte dei progetti che ho fatto sono state le applicazioni proprietarie per l'uso all'interno di grandi aziende, e in quei casi i servizi di autenticazione esterni sono raramente un'opzione, ma l'autenticazione è invece gestite da qualche servizio interno (ad esempio Active Directory).

Devo succedere a far parte di un progetto che avrebbe costruito un sito web pubblico senz'altro provare a fare uso di qualcosa come OpenID, invece di ospitare la mia autenticazione.

Answer 6

Uno dei problemi è una combinazione di non inventato qui e la diffidenza delle autorità esternalizzati per l'identità (anche pseudonomous). Una buona write-up è qui:

• ti fidi il provider di identità ?

Inoltre, penso che potrebbe essere l'inerzia. Senza una killer application per alimentarlo, le persone sono lenti a migrare. Dato l'aumento del numero di facebook-integrazioni che ho visto ultimamente penso che siamo sulla cima di un pendio ripido, per entrare in quel mondo.

Answer 7

Come un altro poster indicato, l'autorizzazione è generalmente specifico dell'applicazione. Cosa si può fare in una sola applicazione varia in modo significativo da quello che si può fare in un altro. Soprattutto in clienti off-the-shelf applicazioni, l'autorizzazione è generalmente più naturale gestita dall'applicazione.

Performance è un'altra preoccupazione. Questo può essere visto ottenendo implementazione XACML di Sun, e usarlo per esternare qualche autorizzazione. È incorrere in costi di rete su entrambi i lati della richiesta che (a seconda del modo in cui voi richiesta di architetto / risposta, ecc) può superare di gran lunga il costo effettivo della decisione di autorizzazione. Costruire che in un'applicazione COTS, dove si hanno meno libertà per l'ottimizzazione delle prestazioni e le cose peggiorare.

Tuttavia, credo che alcune delle aree più promettenti sono circa la conformità alle normative. Ci sono alcune autorizzazioni che non variano a seconda dell'applicazione. Trasferimento di informazioni o materiali di proprietà o classificati, per esempio. In questi casi, un caso forte può essere effettuato per lo stesso controllo esistente in ogni applicazione, perché il contrario è così male. Avere un qualsiasi numero di implementazioni e regole per lo stesso controllo di accesso è un incubo gestione. Un posto facile per iniziare con un quadro di controllo come XACML può essere quella di iniziare con quello che qualcuno può vedere, e poi lavorare fuori per quello che qualcuno può fare.

Answer 8

Penso che dipende dal tipo di progetto si lavora. Se il cliente vuole conservare l'autorizzazione non c'è modo di usare OpenID ... I sviluppare un piccolo progetto che utilizzano Google Apps del motore e per questo io uso google per fare l'autorizzazione. Quindi dipende fortemente dal tipo di progetto.

Answer 9

Diverse ragioni:

1. Come alcuni dei commenti dimostrate, v'è una percezione generale che "l'autorizzazione è locale", che implica che ci sono poche possibilità di riutilizzo del costoso da mantenere-at-alta qualità "attributi oggetto" necessari per decisioni di accesso importanti. (Credo che ci sia un alto potenziale riutilizzo poiché alcune leggi / erg sono ampiamente applicabili, ma piena discussione di questo è troppo lungo per questo formato.)
2. La mancanza di un'infrastruttura di dati: per applicare il controllo degli accessi basato su policy tra le organizzazioni (me usando / fidarsi l'autorizzazione di qualche altro org ( "AuthZ") i dati per sbloccare l'accesso ai miei dati) richiede, come minimo, che ho capito la semantica dell'attributo (che cosa è un "funzionario di-enforcemment"? che cosa è un "cittadino degli Stati Uniti".) Dopo di che, sarebbe bello avere facile capire gli standard di qualità di attributi e certificazione di terza parte dello stesso. (Alcuni possono osservare che questi requisiti sono analoghi ai requisiti di PKI interoperabilità:?. Come è che venendo E questo è solo per un pezzo di dati, più roba di supporto)
3. Impatto sui ruoli / responsabilità: esternalizzazione dell'autorizzazione, sia ai "ruoli" o di "attributi" o di "attributi con la politica digitale", significa che il "proprietario dei dati" locale perde il controllo della risorsa. Si alleggerisce anche un notevole lavoro e la responsabilità per il mantenimento di elenchi di utenti. Questo tipo di cambiamento eleva attuazione AuthZ esterno da un problema tecnico ad una questione organizzativa con un lato della politica.
4. La maggior parte delle organizzazioni non sanno e non hanno scritto giù quello che le loro politiche sono. L'accesso può essere "chi chiede" o "chi chiede e mi piace" o "chi mi può dare qualcosa, come l'accesso ai propri dati." Le vere e proprie regole applicate possono essere piuttosto brutto quando sono costretti allo scoperto esprimendo loro in un linguaggio della politica. E l'insieme di abilità per la buona resa di politiche scritte nelle politiche digitali non crescono sugli alberi, sia. In realtà, il set di abilità è business analyst o un avvocato, e non IT ragazzo, e gli strumenti per quelle persone sono rare o inesistenti.
5. Quando si dispone di una regola di politica solida, è probabile che scoprire che gli attributi necessari per elaborarlo non esistono - non sono in genere il tipo di cosa che si trova già in AD. Numero di telefono non è utile come un attributo AuthZ, e anche "Organizzazione" non è probabilmente adeguata per la maggior parte legge o regs si può effettivamente documento. Che non è nemmeno menzionare i work-around e approssimazioni è necessario implementare (e ottenere approvato) per esprimere le esigenze della politica come "probabile causa".
6. Relativamente trattabili, ma ancora reale, è che molte applicazioni COTS molto diffusi non supportano autorizzazione esterno, e molte app-sviluppatori non sono abituati a fare esternalizzazione, e così sarà (a) cercare di parlare fuori di esso; o (b) imparare sul vostro centesimo, e lo fa male.

---

Suoni piuttosto male, vero? Quindi, mi permetta di concludere dicendo Penso che il gioco vale la candela, nonostante tutto questo. L'elenco dei potenziali benefici è per un altro post in un altro momento.

In bocca al lupo!

Answer 10

Sono d'accordo con il punto di Joseph sull'autorizzazione essere altamente specifica applicazione.

Ma oltre a questo, l'outsourcing autorizzazione porta anche in una delle principali preoccupazioni di rischio: dal momento che l'autorizzazione è altamente specifica applicazione e granulari, una volta che si externalize autorizzazione a un fornitore di servizi, la migrazione o la sostituzione di tale fornitore diventa un compito quasi impossibile. Siete sul gancio irrevocabilmente.

Quindi, nella valutazione dei tuoi rischi e benefici, affari ragionamento si spinge a evitare di andare con una dipendenza così difficile.

Answer 11

Per me personalmente, questa è la prima cosa che io abbia mai sentito parlare di autorizzazione esterno .. Quindi, potrebbe essere solo la mancanza di consapevolezza.

Googling ora ..