2015-07-02 11 views
5

Ho visto di recente l'accesso a Cosmos' WebHDFS in FIWARE Lab è stato protetto con OAuth2. So che devo aggiungere un token OAuth2 alla richiesta per continuare a utilizzare WebHDFS, ma:OAuth2 accesso a Cosmos 'WebHDFS in FIWARE Lab

  • Come posso ottenere il token?
  • Come viene aggiunto il token alla richiesta?

Senza il token, l'API restituisce sempre:

$ curl -X GET "http://cosmos.lab.fi-ware.org:14000/webhdfs/v1/user/gtorodelvalle?op=liststatus&user.name=gtorodelvalle" 
Auth-token not found in request header 

risposta

3

Sì, ora WebHDFS accesso è protetto con OAuth2. Questo fa parte del meccanismo generale per pretendere le API REST in FIWARE, che esegue l'autenticazione e l'autorizzazione. Puoi trovare maggiori dettagli here.

Prima di tutto, è necessario richiedere un token OAuth2 al generatore di token Cosmos. Questo è un servizio in esecuzione in cosmos.lab.fiware.org:13000. È possibile farlo utilizzando qualsiasi client REST, il modo più semplice sta usando il comando ricciolo:

$ curl -k -X POST "https://cosmos.lab.fiware.org:13000/cosmos-auth/v1/token" -H "Content-Type: application/x-www-form-urlencoded" -d "grant_type=password&[email protected]&password=xxxxxxxx" 
{"access_token": "qjHPUcnW6leYAqr3Xw34DWLQlja0Ix", "token_type": "Bearer", "expires_in": 3600, "refresh_token": "V2Wlk7aFCnElKlW9BOmRzGhBtqgR2z"} 

Come si può vedere, le credenziali Lab FIWARE sono tenuti nel payload, sotto forma di un tipo di sovvenzione basata su password .

Una volta ottenuto il token di accesso (nell'esempio precedente, è qjHPUcnW6leYAqr3Xw34DWLQlja0Ix), è sufficiente aggiungerlo alla stessa richiesta WebHDFS che si stava eseguendo in passato. Il token viene aggiunto utilizzando l'X-Auth-Token intestazione:

$ curl -X GET "http://cosmos.lab.fiware.org:14000/webhdfs/v1/user/frb/path/to/the/data?op=liststatus&user.name=frb" -H "X-Auth-Token: qjHPUcnW6leYAqr3Xw34DWLQlja0Ix" 
{"FileStatuses":{"FileStatus":[...]}} 

Se si tenta la richiesta di cui sopra con un token a caso il server restituirà il token non è valido; questo è perché avete non autenticati correttamente:

$ curl -X GET "http://cosmos.lab.fiware.org:14000/webhdfs/v1/user/frb/path/tp/the/data?op=liststatus&user.name=frb" -H "X-Auth-Token: randomtoken93487345" 
User token not authorized 

Allo stesso modo, se si utilizza un gettone valido, ma si cerca di accedere a un altro userspace HDFS, si otterrà la stessa risposta; questo è perché siete non autorizzato di accedere a qualsiasi spazio utente HDFS ma quello di tua proprietà:

$ curl -X GET "http://cosmos.lab.fiware.org:14000/webhdfs/v1/user/fgalan/path/tp/the/data?op=liststatus&user.name=fgalan" -H "X-Auth-Token: qjHPUcnW6leYAqr3Xw34DWLQlja0Ix" 
User token not authorized 

IMPORTANTE AGGIORNAMENTO:

Dall'estate 2016, cosmos.lab.fiware.org non è workin più. Invece, sono stati impostati un paio di cluster, storage.cosmos.lab.fiware.org e computing.cosmos.lab.fiware.org. Per quanto riguarda il server di autenticazione di Cosmos, attualmente viene eseguito in computing.cosmos.lab.fiware.org, porta TCP/13000.

+0

Perché usando' X-Auth-token' (un'intestazione OpenStack) invece di utilizzare l'intestazione utilizzata nello standard OAuth2: 'Autorizzazione'? –

+0

Stiamo utilizzando FIWARE PEP Proxy nel mezzo (https://github.com/ging/fi-ware-pep-proxy). Quel componente specifica l'uso di 'X-Auth-Token' in questo pezzo di documentazione: https://github.com/ging/fi-ware-pep-proxy#how-to-use. – frb

+0

Ora, queste soluzioni non funzionano :( – miguelbemartin

1

La richiesta deve essere giusta:

ricciolo -X POST "https://cosmos.lab.fi-ware.org:13000/cosmos-auth/v1/token" -H "Content-Type: application/x-www-form-urlencoded" "grant_type -d = Password & username = utente @ dominio .com & password = yourpassword" -k

l'url non era corretta, il corretto è https://cosmos.lab.fi-ware.org:13000

-k è per disattivare la verifica del certificato

+0

Hai ragione con l'opzione '-k', ho dimenticato di dirlo (grazie!). Per quanto riguarda l'endpoint, sia' cosmos.lab.fiware.org' che 'cosmos. lab.fi-ware.org' sono risolti sullo stesso indirizzo IP – frb

+0

L'utilizzo di -k è considerato una pratica estremamente negativa per qualcosa di diverso dallo sviluppo locale Quando verrà installato un certificato ssl validato da terze parti? – amn41

Problemi correlati