Come posso integrare gli ambienti di sviluppo web locali con una soluzione SSO centrale?

Question

Come posso integrare gli ambienti di sviluppo web locali con una soluzione SSO centrale?

#1 da (3 voti)

5

Abbiamo un'applicazione web a pagina singola e abbiamo un nuovo sito SSO (anch'esso nostro) che utilizza OAuth2 e stiamo cercando di collegarli.

Nelle distribuzioni di produzione / staging / CI, è facile agganciare tutto. Ad esempio:

in fase di produzione avremo https://app.company.com per accedere al nostro punto di backend dei prodotti a https://sso.company.com per auth e viceversa
su CI avremo https://app.ci.company.com per accedere al nostro back-end di sviluppo e puntare a https://sso.ci.company.com per auth.

Quando eseguiamo lo sviluppo sull'app, accediamo localmente a qualcosa come http://localhost:8000/ e punta al backend dello sviluppo condiviso. In passato, abbiamo avuto solo un'autenticazione contro il backend di sviluppo (ottenendo le credenziali dell'utente finale e inviandolo), ma ci piacerebbe farlo cablare per usare SSO per l'autenticazione.

La domanda sorge da come possiamo farlo senza che nessuno sviluppatore voglia sviluppare localmente la necessità di configurare e personalizzare il proprio servizio SSO. Nello specifico, possiamo usare l'SSO dev / CI condiviso e puntare alle nostre distribuzioni locali?

Ciò che abbiamo considerato:

Utilizza un file proxy / file hosts e aggiungi http(s)://sso.ci.company.com a http(s)://localhost:8000 . Questo ci impone di impostare localmente HTTPS o di avere l'SSO diretto su un URL non HTTPS. Inoltre, l'installazione è un po 'difficile.
Fai reindirizzare la nostra app locale all'SSO con un argomento che si identifica e utilizza l'SSO per sapere dove reindirizzare. Ad esempio, reindirizza a https://sso.ci.company.com/?appUrl=localhost:8000 . Questo ci obbliga a dare un reindirizzamento a tempo indeterminato nell'SSO che dovremmo disattivare per la produzione ed è un po '"strano" ma funziona e può essere inserito nella scatola nera.
Basta eseguire l'SSO localmente su ogni dev box. Questa è fondamentalmente la non-soluzione in quanto richiederebbe un sacco di setup per arrivare a uno script "one box che può eseguire tutto", e nega uno dei nostri preziosi vantaggi al momento in cui sostanzialmente tutto quello che devi fare è controllare estrai il codice su qualsiasi sistema e fallo funzionare. Ho visto questo fatto prima però comunemente (spesso in cima alle macchine virtuali di sviluppo); Mi piacerebbe solo esplorare le opzioni a cui siamo potenzialmente più vicini.

C'è una soluzione a questo tipo di problemi o aspetti delle nostre idee che non abbiamo ancora considerato?

web-development development-environment sso

posta Steven Xu 15.10.2013 - 03:43

fonte

1 risposta

Leggi altre domande sui tag web-development development-environment sso

che algoritmi di ordinamento utilizza OrderBy Sta usando la tipizzazione statica della soluzione per progettare il dominio e ridurre il numero di errori?

score 3 · Answer 1

In precedenza ho lavorato in un ambiente in cui disponevamo di ambienti SSO e di sviluppo locale.

Il problema chiave che deve essere risolto con SSO e gli ambienti di sviluppo è che il cookie del dominio deve poter essere recuperato quando si colpisce l'ambiente dev locale.

Ammettiamolo, parte di questo ha a che fare con il modo in cui impostiamo l'ambiente (e molti anni fa sono stato coinvolto in questo). Era un ambiente poliglotta con un misto di html statico, vecchio perl cgis, un server weblogic per Java EE, un server iis per alcune app che dovevano essere eseguite con asp e qualcosa che l'ingegneria funzionava. Il modo in cui SSO comunicava queste informazioni era che un proxy inverso bloccava nelle intestazioni http il nome utente autenticato e tutti gli accessi associati che avevano. In questo modo, indipendentemente da chi l'ha ottenuto, potrebbero guardare le intestazioni e continuare da lì.

Prima di tutto, il DNS è stato impostato in modo che ogni sviluppatore avesse un nome host nel dominio 'dev.company.com' - quindi 'sxu.dev.company.com' (per te) e 'jsmith.dev.comapny .com 'per John Smith. Tutti questi nomi (CNAMES) indicavano un singolo proxy inverso comune (il proxy inverso aveva pochissimo su di esso) che poi guardava il nome dell'host virtuale che stava arrivando e quindi inoltrava la richiesta al computer dello sviluppatore appropriato. Si noti che le interazioni con il codice SSO erano completamente contenute nel proxy inverso, quindi non è necessario installare altre librerie da nessun'altra parte.

L'interazione con l'infrastruttura consisteva semplicemente nell'aggiungere un altro cname a common.dev.company.com ogni volta che avevamo una nuova assunzione, e quindi dovevamo aggiungere il loro nome a un file che era stato eseguito attraverso alcuni macro m4 per generare l'apache corretto file http.conf per il proxy inverso (che ha richiesto un po 'di lavoro il primo momento in cui l'abbiamo fatto).

Con questa idea, potresti prendere in considerazione la possibilità di impostare un proxy inverso che agisca semplicemente per inoltrare tutto al computer dello sviluppatore appropriato tramite http (indipendentemente dal tipo di connessione ricevuta). https://sxu.ci.company.com/xyz va al proxy inverso, che gestisce https, e lo inoltra alla tua casella di sviluppo a http://10.1.2.3/xyz . Il trucco con questo approccio che devi osservare è che se hai dei percorsi assoluti nel codice, o se il server dello sviluppatore cerca di essere consapevole di dove è installato e del protocollo utilizzato per generare un link dello stesso formato, le cose potrebbero andare un po 'confuse (questo è un termine tecnico).

Questo evita il problema di configurare https localmente (solo un server ha https in esecuzione) o di modificare il server sso per passare a un URL non-https. Hai diverse impostazioni in un posto diverso.

Non sono sicuro che le tue caselle di sviluppo locale rispondano all'accesso diverso da localhost (è una configurazione valida), in tal caso, quelle dovranno essere modificate perché la richiesta proviene dal proxy in questo caso invece del browser locale.

Voglio sottolineare il beneficio collaterale che significherà che altri sviluppatori possono colpire il tuo ambiente (vuoi che qualcuno riproduca un bug mentre stai guardando i file di log che non sai come repo - avere loro colpiscono il tuo server).

La seconda opzione è un approccio non-standard (ricordo che diversi sistemi SSO di produzione sono stati configurati per consentire un set limitato di parametri tipo appUrl - in parte in modo che la persona esterna possa usare SSO e andare a una pagina specifica una volta effettuato l'accesso. Aggiungere una mappatura di 'dev- > localhost: 8000' consentirebbe questo, tuttavia sarà necessario riconsiderare come affrontare il problema del localhost non ottiene i cookie di company.com Probabilmente dovrai modificare le tue caselle locali per identificarti come localhost.company.com affinché funzioni.