search

italia / spid-dotnet-sdk

SPID authentication library for .NET
BSD 3-Clause "New" or "Revised" License
28 stars 15 forks source link

Sviluppo plugin per autenticazione SPID in .NET #1

Closed alranel closed 6 years ago

alranel commented 7 years ago

Ci sono due strade per implementare un plugin per .NET:

  1. usare un middleware come Shibboleth
  2. implementare tutto direttamente nel plugin (self-contained)

Per i dettagli sulle due possibili soluzioni si vedano le considerazioni scritte nell'analoga issue per SPID-Django.

Lo scopo di un plugin SPID per .NET dovrebbe essere quello di:

Per l'implementazione basata su Shibboleth (opzione 1): bisogna adattare uno Shibboleth a Windows partendo dal playbook Ansible già disponibile per Linux, e configurarlo su IIS. Per l'implementazione self-contained (opzione 2): qual è la migliore libreria SAML?

sklivvz commented 7 years ago

Quale versione di dotnet bisogna supportare? dotnet e' fondamentalmente diverso da dotnet-core. Quali deployment environment?

alranel commented 7 years ago

Mi sembra più strategico e future-proof puntare su .NET Core, e quindi consigliabile. Poi abbiamo un tema di applicativi legacy .NET che vorranno utilizzare SPID, per cui anche un'eventuale implementazione in .NET è benvenuta, sebbene con minore priorità. Per il deployment dovremmo supportare la casistica più ampia (ma qui parliamo di una libreria, non di una app, quindi forse il deployment è irrilevante?).

sklivvz commented 7 years ago

OK, do un'occhiata allo scope esatto e poi ti faccio altre domande :-D

SbGibson commented 7 years ago

Io propenderei per una soluzione full .NET, senza Shibboleth che poi ha problemi di deployment in IIS, ambienti distribuiti etc. Piuttosto si potrebbe prendere in considerazione Kentor.AuthServices che fa molto del lavoro che servirebbe se non ci sono problemi di licenza. Quanto alla tecnologia secondo me lo scopo dell'sdk dovrebbe essere innanzitutto quello di facilitare l'integrazione di SPID in tutta una serie di servizi già esistenti o in fase di sviluppo avanzato e puntare su .NET Core credo sia un pò presto anche se sicuramente più orientato al futuro. Un httpmodule + mvc controller a mio parere sarebbe la forma che ne massimizzerebbe l'utilità. Ricordiamoci di Mono :-)

sklivvz commented 7 years ago

Penso che molto lavoro possa in realtà essere condiviso fra dotnet e dotnet-core. Il grosso della divergenza e' la dipendenza da System.Web nel primo e l'implementazione come middleware del secondo. Bisogna vedere nei dettagli se l'interazione abbia bisogno di toccare queste parti o se possa essere abstracted away.

Sono d'accordo che dotnet sia la soluzione piu' ovvia nei progetti brownfield, ma credo che come investimento sia importante pensare al futuro e non forzare nuovi sviluppi ad usare versioni vecchie del prodotto. Propongo di fare entrambe le cose e a limite dividere il ticket in due se il lavoro condiviso fosse troppo poco.

--

Marco Cecconi

2017-10-03 12:41 GMT+02:00 SbGibson notifications@github.com:

Io propenderei per una soluzione full .NET, senza Shibboleth che poi ha problemi di deployment in IIS, ambienti distribuiti etc. Piuttosto si potrebbe prendere in considerazione Kentor.AuthServices che fa molto del lavoro che servirebbe se non ci sono problemi di licenza. Quanto alla tecnologia secondo me lo scopo dell'sdk dovrebbe essere innanzitutto quello di facilitare l'integrazione di SPID in tutta una serie di servizi già esistenti o in fase di sviluppo avanzato e puntare su .NET Core credo sia un pò presto anche se sicuramente più orientato al futuro. Un httpmodule + mvc controller a mio parere sarebbe la forma che ne massimizzerebbe l'utilità. Ricordiamoci di Mono :-)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/italia/spid-dotnet-sdk/issues/1#issuecomment-333804600, or mute the thread https://github.com/notifications/unsubscribe-auth/AAtysVrls4_tPSWUDQubtcSxs8HHGn_Rks5sog89gaJpZM4PmBhh .

BrightSoul commented 7 years ago

Penso che molto lavoro possa in realtà essere condiviso fra dotnet e dotnet-core.

Penso anch'io. Dovremmo sforzarci di inserire il grosso della logica in un progetto class library che possiamo compilare come libreria .NET Standard 1.x o 2.0 ed eventualmente per il .NET Framework 3.5/4.5. Poi, per i singoli casi d'uso (ASP.NET MVC, ASP.NET CORE, ...) si possono creare altri progetti da distribuire come pacchetti NuGet separati.

fradel commented 7 years ago

Buongiorno :-) Mi permetto di esprimere la mia considerazione: concordo pienamente con @SbGibson, mi sembra decisamente prematuro sposare ("solo") aspnet.core, teniamo a mente che molti sistemi, già a regime nella PA, sono stati sviluppati con le precedenti versioni di .net, le versioni 3.5/4.5, hanno un'eredità di quasi 10 anni. Giusto guardare con un occhio al futuro, ma sarebbe quantomeno superficiale* ignorare il presente. Condivido sia la scelta httpmodule + mvc controller che quella di usare Kentor.AuthServices (personalmente non l'ho mai utilizzato ma leggendo sembra una scelta quasi obbligata).

Detto questo, mi rendo disponibile a portare avanti il progetto :-)

ncarandini commented 6 years ago

Con la PR #7 di cui @alexrj dovrebbe fare a breve il merge si completa la prima fase di sviluppo, fornendo una libreria stabile e utilizzabile anche in produzione.

Spero già domani di procedere alla pubblicazione del pacchetto Nuget, utilizzabile sia col .NET Framework (4.6.1 e successivi) per applicazioni ASP.NET sia con il .NET Core 2.0 per applicazioni ASP.NET Core 2.0.

Provate ad utilizzarla e utilizzate le issues per postare eventuali problemi e richieste di funzionalità. Ovviamente ogni contributo è ben accetto!