Autenticazione CAS di un servizio Web RESTful

Question

La mia applicazione deve accedere a un servizio web RESTful in esecuzione su un server diverso. Questo servizio Web utilizza l'autenticazione CAS e, quando lo utilizza attraverso il browser, reindirizzerà al login CAS se l'utente non è già autenticato. Non esiste alcun metodo per accedere effettivamente tramite CAS. La mia applicazione utilizza anche CAS in modo che gli utenti vengano autenticati

Mi piacerebbe accedervi tramite JQuery/Ajax, ma il server non sembra essere configurato per JSONP che a mio avviso è essenziale a causa del problema interdominio .

Ora, potrei fare le richieste Ajax tramite il mio server, il che porta alla mia domanda: senza alcun metodo di accesso CAS per chiamare il mio server, come posso "dire" al servizio web che l'utente è autenticato?

Quindi, in primo luogo, voglio chiarire cosa sta succedendo tra il browser, il CAS e il servizio RESTful, e come viene gestita l'autorizzazione senza alcun trasferimento esplicito delle credenziali. In secondo luogo, voglio vedere come/se posso replicare ciò quando chiamano il servizio dal mio server- non sarebbe la stessa sessione di una richiesta dal browser quindi non ci sarebbe nessun token di autorizzazione CAS, ma non lo faccio vedere come ottenerne uno o fornirlo.

Answer 1

Per la domanda 1 sul modo in cui il/Single Sign autenticazione opere:
Quando si effettua il login al server CAS (diciamo security.example.com) sarebbe impostare un cookie nel browser per il dominio security.example.com . Un flusso tipico quando si accede ai file protetti tramite il browser su un'applicazione utilizzando l'autenticazione e validazione filtri standard CAS assomiglia:

1. filtro CAS autenticazione configurato per l'applicazione verifica se l'oggetto utente è in sessione. Se sì, l'utente è autorizzato a passare
2. In caso contrario, il filtro di autenticazione CAS reindirizza il browser alla pagina di accesso CAS. In un unico scenario, il server CAS riconosce il proprio cookie, controlla se l'applicazione è registrata e partecipa al single sign on - se sì reindirizza il browser all'applicazione con un ticket di servizio.
3. CAS filtro convalida configurato l'applicazione identifica il ticket di servizio e contatti CAS server per la convalida del biglietto e la creazione di oggetti affermazione

Per l'intero flusso di lavoro è necessario cookie e la gestione delle sessioni di lavoro.

Per la domanda 2 su come gestire l'autenticazione sul lato server:
abbiamo avuto un problema simile nella nostra applicazione e utilizzare 2 modi diversi per ottenere intorno ad esso:

1. Utilizzare un utente del sistema interno e fare un accesso da server a server passando le credenziali di questo utente usando le intestazioni di autenticazione di base. Naturalmente è necessario disporre di filtri appropriati configurati per gestire un accesso non interattivo con token di autenticazione di base. Questo è facile da implementare, ma ha svantaggi evidenti come avere questo utente di sistema speciale, l'applicazione che vede la password degli utenti ecc.
2. Utilizzare proxy authentication. In questo approccio quando l'utente viene autenticato per l'applicazione 1, genera anche un ticket proxy che deve essere utilizzato da application2 (chiamata da server a server). Questo ticket proxy può essere passato in comunicazione server-server in modo che l'applicazione 1 acceda all'applicazione 2 per conto dell'utente

Answer 2

Im utilizzando tale impostazione in uno dei miei progetti. Alcune delle implementazioni CAS consentono l'autorizzazione tramite una chiamata di riposo. Prova ad aggiungere un'intestazione di autorizzazione di base (codifica Base 64 di Username e Password). Sembra qualcosa di simile

Header ("Autorizzazione", "Basic")

tentare di accedere alle API REST utilizzando REST client su Mozilla per il debug anche. Ti aiuterà davvero a capire le varie intestazioni ecc.