1 / 23

Offerta per la realizzazione del servizio IMOTP (Internal Mobile One Time Password)

Offerta per la realizzazione del servizio IMOTP (Internal Mobile One Time Password). per. Documenti di riferimento. 20070723 OTPxInterno.R01.ppt : presentazione con la descrizione della piattaforma e della sua architettura [1] 21ITERU_IMOTP_1_14.doc : requisiti utente [2]

Download Presentation

Offerta per la realizzazione del servizio IMOTP (Internal Mobile One Time Password)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Offerta per la realizzazione del servizio IMOTP (Internal Mobile One Time Password) per

  2. Documenti di riferimento • 20070723 OTPxInterno.R01.ppt: presentazione con la descrizione della piattaforma e della sua architettura [1] • 21ITERU_IMOTP_1_14.doc: requisiti utente [2] • 21TESP07_IMOTP_09_.doc: specifiche funzionali [3] Nota: questi documenti sono stati prodotti da Telecom Italia e rappresentano il punto di riferimento per la presente offerta e per la successiva analisi e implementazione della soluzione

  3. Obiettivi di progetto • IMOTP (Internal Mobile One Time Password) è una nuova piattaforma di autenticazione ai servizi basata su OTP via SMS che Telecom Italia vuole rendere disponibile ai propri dipendenti per accedere alle risorse aziendali • L’obiettivo primario è quello di accrescere il livello di sicurezza per gli accessi esterni a servizi e risorse aziendali, superando il paradigma User+Password statica • La soluzione proposta è migliorativa anche rispetto al mercato di riferimento che vede la presenza di token hardware/software (Rif [1]) • La soluzione deve essere esportabile presso altri clienti

  4. Ambito del progetto • La soluzione proposta, in linea con la pre-analisi già svolta dalla stessa Telecom Italia, prevede la realizzazione dei moduli software e la messa in opera e configurazione delle necessarie infrastrutture atti ad implementare il servizio IMOTP soddisfacendo i requisiti, l’architettura e le modalità operative descritti nella presente offerta

  5. Confini del progetto • La presente offerta comprende • le attività di analisi, progettazione, implementazione della architettura fisica e del sistema di autenticazione RADIUS e sincronizzazione directory • le attività di analisi, progettazione, implementazione dei componenti software: • web methods • componenti software accessori • Il dettaglio di quanto incluso ed escluso è specificato nel seguito

  6. Requisiti utente e di sistema 1/3 • I requisiti di riferimento sono quelli descritti nel documento [2], ad esclusione della parte relativa a OTPServer (v. Esclusioni), riportiamo nel seguito i punti principali da considerarsi come macro-requisiti, ognuno dei quali sarà ulteriormente dettagliato in fase di analisi • User Experience • I dipendenti abilitati al servizio via OTP devono ricevere all’atto del provisioning un PIN statico che sarà poi aggiunto all’OTP per formare la password di accesso • I dipendenti abilitati hanno a disposizione tre canali per effettuare la richiesta di accesso: IVR, SMS, IP • Il sistema, previa verifica, invia l’OTP all’utente via SMS • L’utente utilizza username e OTP+PIN per accedere al servizio • Il numero di richieste nell’unità di tempo è limitato ed è un parametro configurabile del sistema • Gli utenti non abilitati che effettuano una richiesta devono ricevere un feedback che li avvisi dell’errore (SMS o e-mail) • L’autenticazione può essere richiesta tutti i giorni della settimana H24

  7. Requisiti utente e di sistema 2/3 • Amministrazione (per i seguenti punti è prevista una GUI amministrativa) • Devono essere gestiti 5 profili di amministrazione (gestione globale, gestione utenze amministrative, gestione utenze applicative, monitoraggio globale, monitoraggio su base servizio) • Provisioning e deprovisioning: deve essere possibile per gli amministratori abilitati effettuare la registrazione degli utenti, previo controllo sul rispettivo AD, seguito da generazione e invio del PIN nonché la disabilitazione o cancellazione degli utenti stessi • Visualizzazione: gli amministratori devono poter visualizzare lo stato e i dati del sistema, degli utenti e dei log • Gestione PIN • Per ogni utente va generato e inviato automaticamente via SMS un PIN al momento del provisioning • Il PIN può essere resettato e reinviato all’utente, e deve essere memorizzato in modalità cifrata • Gestione servizi • L’applicazione deve permettere di gestire l’anagrafica dei servizi, delle associazioni con gli utenti e con gli amministratori (visualizzazione, inserimento, modifica e cancellazione)

  8. Requisiti utente e di sistema 3/3 • Reportistica • Il sistema deve essere corredato di adeguata reportistica disponibile sia in formati esportabili (xml) che da GUI (da inserire nell’interfaccia amministrativa) • I principali dati da rendere disponibili riguardano: • Numero OTP richieste (su base utente, totali, su base canale di accesso) • Numero di utenti (attivi, applicativi su base servizio e totali) • Statistiche sulle richieste OTP annullate per superamento soglia richieste nell’unità di tempo • Saranno implementati fino ad un massimo di 10 template di report • Altri requisiti • Il sistema deve supportare inizialmente un numero di utenti pari all’utenza Griffon (60.000 totali, 30.000 contatti al giorno) • L’architettura deve essere scalabile • Il collegamento fra i componenti deve avvenire su canali sicuri • Possibilità di evoluzione • Il sistema contiene tutte le caratteristiche utili ad un futuro eventuale utilizzo di autenticazione su base servizio: attualmente non è prevista la richiesta su base servizio, tuttavia al momento della richiesta di OTP viene registrato il servizio da cui giunge la richiesta stessa (se fornito, come nel canale IP); se al momento della verifica dell’account viene riconosciuto il servizio da cui proviene la richiesta può essere eventualmente confrontato con il servizio che ha richiesto la OTP.

  9. Metodologia di progetto

  10. ISA Server 2006 Radius Client Active Directory otp.local Exchange Server Soluzione Proposta: Flusso di Autenticazione • L’utente si autentica sull’LDAP con la OTP • Il Proxy Client invia una richiesta di autenticazione RADIUS al Radius Server • Il RADIUS Server verifica con l’LDAP le credenziali OTP • Le credenziali OTP sono validate • Grant all’accesso • ISA Server accede con le credenziali (Kerberos Constrained Delegation) aulla risorsa richiesta (OWA) • 8. L’utente utilizza la risorsa 8 1 5 2 6 7 RADIUS Server 3 4

  11. Architettura Logica Software AD Telecom/Cliente OTP Server Allineamento AD • OTP Manager • WebService • DBAdmin • ADOTP • Allineamento AD • Timeout Manager • Report Engine • BatchProvisioningTools in verde le parti da realizzare di competenza del progetto Invio SMS OTP Servizi: web mail, bid-1, … Richiesta generazione OTP Accesso al servizio Console I/O Controllo di accesso ai servizi Verifica OTP Richiesta accesso al servizio Gestione Richiesta OTP GUI Amministratori OTP Request Channels: IVR – IP - SMS Services Access Channels: RAS, VPN, WEB, … Richiesta accesso al servizio Richiesta OTP Provisioning Invio PIN Utente

  12. SMS Gateway ISA Server 2006 Radius Client Risorsa da accedere Architettura Logica di Sistema Trust LDAP/S RADIUS Server Telecomitalia Users Replicazione Attributi LDAP Otpuser Otp-password OTP Management Platform otpdomain HTTPS NOTA: l’autenticazione RADIUS di un utente OTP sul servizio OWA ha funzionato nei test preliminari del nostro laboratorio. Tuttavia ci riserviamo di confermare questa soluzione (per inizio della prossima settimana) a valle di una fase di test più approfondita

  13. Architettura Fisica

  14. Componente Hardware La componente Hardware comprende: • Server Domain Controller Active Directory con la funzione di LDAP server e RADIUS Server (IAS) • Server ISA Server 2006 come firewall di frontiera e come Radius CLIENT verso il DC per l’autenticazione degli utenti con password OTP • Server Microsoft Reporting Server per la generazione di Report di utilizzabilità della piattaforma OTP • Server per Web Services di interfacciamento OTP e Web Server di Amministrazione • Server MS SQL 2005 come Database di Piattaforma Su Tutti i server (fisici e virtuali) verranno installati degli agent di monitoraggio MOM 2005 che invieranno i messaggi ai sistemi di monitoraggio indicati da TelecomItalia

  15. Dimensionamento Hardware 1/2

  16. Dimensionamento Hardware 2/2

  17. Componenti della soluzione • Web Service OTP Manager come da specifiche • Componente di gestione scadenza password • DB locali di supporto alle funzionalità amministrative • GUI Amministrativa • GUI Reportistica • Tool di batch-provisioning configurabile • Sistema di autenticazione LDAP • Firewall con funzioni di RADIUS Client verso l’LDAP OTP • Sistema atto alla generazione dei report dei servizi • Componente MOM che si aggancia al MOM centralizzato definito dal cliente per il monitoraggio dei servizi di piattaforma • Componente con scopo di allineamento degli attributi stabiliti dal cliente tra l’LDAP OTP e quello di Telecomitalia

  18. Task di progetto • I task di progetto previsti si articolano nelle seguenti fasi • Attività di Project Management che si estende durante tutta la durata del progetto • Attività di supporto sistemistico che si estende durante tutta la durata del progetto • Attività di revisione e finalizzazione dell’analisi, con lo scopo di produrre la documentazione di dettaglio utile agli sviluppatori • Attività di installazione e configurazione dell’ambiente di laboratorio • Sviluppo (alto grado di parallelizzazione per lo sviluppo dei moduli dell’OTP Manager per rispettare i tempi richiesti) • Integrazione e test in ambiente di laboratorio dei singoli moduli/funzioni • Installazione, Test e Collaudo in ambiente di pre-esercizio e produzione Telecom (PVV e PQR) • Configurazione dei report secondo le richieste del cliente • Assistenza post-avviamento: dopo il rilascio completo del sistema, l’assistenza post-avviamento sarà garantita per al massimo 3 settimane prevedendo la presenza continuativa on-site di una risorsa (1 FTE) applicativa e/o sistemistica a seconda delle necessità

  19. Vincoli • Tecnologia Microsoft Framework .Net 2.0 o superiore • Sviluppo delle componenti in Visual C# • Protocollo https per la comunicazione con i web services • Database SQL Server 2005 o superiore per il DB Admin interno • Ad inizio progetto dovranno essere fornite da TI, secondo le tempistiche che verranno concordate nella prima riunione di inizio progetto, tutte le informazioni che Reply riterrà utili al fine della realizzazione del sistema • Completo supporto da parte di TI o da terze parti competenti sui sistemi da interfacciare

  20. Esclusioni • Modulo OTPServer (Generazione OTP da scheda HW certificata) e corrispondente GUI di amministrazione • Licenze del software • Hw e Sw per invio e ricezione SMS • Interfaccia utente per la richiesta OTP sui tre canali previsti • GUI di interrogazione dei servizi diverse da quelle indicate • Integrazione con sistemi di Identity Management (per il piccolo numero di utenze amministrative previsto è sufficiente realizzare la GUI di gestione, eventuali workflow di approvazione sono da considerarsi al di fuori del progetto) • Help Desk telefonico citato in [2] • I server fisici che dovranno ospitare le macchine virtuali, e la fornitura hardware in genere

  21. Tempi e costi • 2,5 mesi (10 working weeks) elapsed a partire dall’accettazione formale della presente offerta. Se si vuole terminare entro gennaio 2008 si deve partire al più tardi il 12 novembre.

  22. Tempi e costi • Costo complessivo: xxx.xxx,00 euro, ripartito nelle seguenti voci • Project Management 5% • Analisi funzionale 12% • Analisi architetturale 6% • Inst/Conf Laboratorio e supporto sistemistico 21% • Sviluppo applicativo e test di integrazione 50% • PVV e PQR 3% • Assistenza post-avviamento 3%

  23. Contattiwww.reply.itinfo@reply.ittel.: +39 06 844341

More Related