mercoledì, settembre 13
Identità digitale e web services
L'ultima sessione parallela del convegno è stata tenuta da Andy West su come rendere sicuri i web service usando l'identità digitale. Tema non nuovo, ma affrontato da una prospettiva tecnica per far capire meglio a cosa si va incontro.
West lavora per la Thomson Learning, una azienda specializzata nella formazione ad alto livello. Sul tema dell'uso dell'identità digitale nei web services hanno svolto un "esperimento" basandosi su un business case reale. E questo business case è lo stesso di ICAR: rendere possibile il trust tra diversi service provider coinvolti in una collaborazione.
Il pattern di interazione preso in considerazione è quello a scambio di messaggi. Naturalmente la base è l'esistenza di relazioni di trust tra le parti che si scambiano messaggi. La "sicurezza" del WS a cui si fa riferimento non ha nulla a che vedere con il fatto di scambiare messaggi su canali SSL. Si tratta di fare sì che un servente possa dare corso a richieste provenienti da un cliente perché conosce l'identità di chi sta usando il cliente. Per ottenere questo risultato sono ricorsi alle specifiche WS-Trust implementate dal prodotto PingTrust di PingID che è stato il loro partner tecnologico.
Il cliente correda la propria richiesta con un insieme di token SAML ottenuti dal proprio STS (Secure Token Service, parte di WS-Trust), il servente valida queste asserzioni. E' importante che il servente non abbia bisogno di usare il STS del cliente, ma possa usare il suo STS che giace nello stesso dominio di trust di quello del cliente, ed è in grado di validare in proprio l'asserzione. Nell'esempio proposto viene usat PingTrust. Come infilare le asserzioni nel messaggio? Nell'esempio che viene presentato, la chiamata tra il cliente e il servente è WS-Trust. AXIS provvede poi a infilare il token SAML nell'header e a passarlo.
Una domanda chiede se sia usato anche un token di identità per il servizio cliente. La risposta è affermativa, l'header contiene sia il token di identità della persona sia quella del cliente. Come da tempo proponiamo per INF-1...
West lavora per la Thomson Learning, una azienda specializzata nella formazione ad alto livello. Sul tema dell'uso dell'identità digitale nei web services hanno svolto un "esperimento" basandosi su un business case reale. E questo business case è lo stesso di ICAR: rendere possibile il trust tra diversi service provider coinvolti in una collaborazione.
Il pattern di interazione preso in considerazione è quello a scambio di messaggi. Naturalmente la base è l'esistenza di relazioni di trust tra le parti che si scambiano messaggi. La "sicurezza" del WS a cui si fa riferimento non ha nulla a che vedere con il fatto di scambiare messaggi su canali SSL. Si tratta di fare sì che un servente possa dare corso a richieste provenienti da un cliente perché conosce l'identità di chi sta usando il cliente. Per ottenere questo risultato sono ricorsi alle specifiche WS-Trust implementate dal prodotto PingTrust di PingID che è stato il loro partner tecnologico.
Il cliente correda la propria richiesta con un insieme di token SAML ottenuti dal proprio STS (Secure Token Service, parte di WS-Trust), il servente valida queste asserzioni. E' importante che il servente non abbia bisogno di usare il STS del cliente, ma possa usare il suo STS che giace nello stesso dominio di trust di quello del cliente, ed è in grado di validare in proprio l'asserzione. Nell'esempio proposto viene usat PingTrust. Come infilare le asserzioni nel messaggio? Nell'esempio che viene presentato, la chiamata tra il cliente e il servente è WS-Trust. AXIS provvede poi a infilare il token SAML nell'header e a passarlo.
Una domanda chiede se sia usato anche un token di identità per il servizio cliente. La risposta è affermativa, l'header contiene sia il token di identità della persona sia quella del cliente. Come da tempo proponiamo per INF-1...
# posted by Franz @ 20:12 
