Комуникационен клиент 1.13Обща информация

1.16Допълнителни функции на комуникационния клиент

Комуникационният клиент предоставя следните няколко функции за АИС:

• 
  Подписване на документ със сертификат на участника
  
• 
  Криптиране на документ с публичния ключ на ЕСОЕД за последващ пренос
  
• 
  Декриптиране на документ с частния ключ на участника
  
• 
  Проверка на подпис на комуникационния сървър на ЕСОЕД и участника в документ
  
• 
  С цел осигуряване на резервираност за изпълнение на процеса по предоставяне на електронни административни услуги, се реализира функционалност на КК за следене на работещ ЕСОЕД в някой от изградените центрове за резервираност при отпадане на ЕСОЕД в основния център.
  

Тъй като описаните методи са чувствителни от гледна точка на сигурността, силно препоръчително е АИС да вграждат тяхната логика – или чрез използването на готовите библиотеки, или чрез използването на средствата, които предоставя платформата на съответната АИС. Реализирането на тези методи като уеб услуга се прави единствено с цел АИС, които по технически причини не могат да реализират тази логика сами, все пак да могат да подписват и криптират документи.

• 
  string Sign(string message)
  

При възникване на грешка се подава SOAP грешка. Грешката може да бъде невалидна схема или грешка при подписването на документа.

• 
  string Encrypt(string message)
  

При възникване на грешка се подава SOAP грешка с описание на възникналия проблем.

• 
  string Decrypt(string message)
  

При възникване на грешка се подава SOAP грешка с описание на възникналия проблем.

• 
  int Validate(string message)
  

Изходен параметър е число, което може да има следните стойности:

• 
  0 – Документът съдържа валиден подпис на участника и валиден подпис на комуникационния сървър на ЕСОЕД.
  
• 
  1 – Документът съдържа единствено валиден подпис на участник. Валиден подпис на комуникационния сървър на ЕСОЕД не е открит. Причините могат да са:
  
  • 
    Не е открит signature елемента на EsoedDetails.
    
  • 
    Signature елемента на EsoedDetails е открит, но подписа е невалиден
    
  • 
    XPath –който е използван при създаване на подписа не е правилен
    
• 
  2 – Документа съдържа единствено валиден подпис на комуникационния сървър на ЕСОЕД. Валиден подпис на участник не е открит. Причините могат да са:
  
  • 
    Не е открит signature елемента на SenderDetails.
    
  • 
    Signature на SenderDetails елемента е открит, но подписа е невалиден
    
  • 
    XPath –който е използван при създаване на подписа не е правилен
    
• 
  3 – Документът НЕ съдържа валиден подпис нито на участник нито на комуникационния сървър на ЕСОЕД. Причините могат да са.
  
  • 
    Не е открит signature елемента нито за SenderDetails, нито за EsoedDetails.
    
  • 
    Съдържанието на документа е променено.
    
  • 
    Не е използван правилния Xpath.
    

При установяване на невалидна схема или при възникване на друга грешка се подава SOAP грешка с описание на възникналият проблем.

1.17Използване на сертификата на участника от комуникационния клиент

Комуникационният клиент е необходимо да има достъп до публичния и частния ключ на участника. Това е нужно за изпълнението на помощните функции, за декриптиране на съобщенията от комуникационния сървър с цел поддържане на информация за сесиите, за подписване на съобщенията от вида CCError и за идентифициране на комуникационния клиент пред комуникационния сървър от името на АИС на транспортно ниво (SSL и клиентски сертификат или друга подобна технология).

Възможни сценарии на комуникация между АИС и КК

В следващите секции се разглеждат възможните сценарии на пренос на документи чрез ЕСОЕД.

1.18Нормален сценарий на пренос

На диаграмата по-долу (Фиг. 3) е показан най-типичния процес на пренос на един документ, когато по време на преноса не възникват никакви грешки и изключения.


Фигура 3
Процесът се състои от няколко стъпки:

1. 
   АИС на изпращащия участник композира XML съобщение.
   
2. 
   АИС на изпращащия участник предава съобщението до комуникационния клиент.
   
3. 
   АИС на изпращащия участник подписва XML съобщението чрез КК1 с неговия частен ключ, отговарящо на дефиницията в тази спецификация.
   
4. 
   АИС на изпращащия участник криптира съобщението чрез КК1 с публичния ключ на ЕСОЕД.
   
5. 
   Комуникационният клиент синхронно изпраща съобщението към комуникационния сървър.
   
6. 
   Комуникационният сървър извършва поредица дейности синхронно:
   
   1. 
      Проверка на изпращащия участник на съобщението в списъка на участниците
      
   2. 
      Декриптиране на съобщението
      
   3. 
      Проверка на схемата на полученото съобщение спрямо схемата на ЕСОЕД.
      
   4. 
      Проверка на синтактична структура на документа спрямо дефинициите в РИО
      
   5. 
      Проверка на подпис на изпращащия участник
      
   6. 
      Проверка на приемащия участник в списъка на участниците
      
   7. 
      Регистриране на метаданните за пренесения документ в базата на ЕСОЕД
      
   8. 
      Добавяне на време на получаване
      
   9. 
      Генериране на служебно синхронно потвърждение към АИС на изпращащия участник
      
7. 
   Комуникационният сървър извършва следните действия асинхронно спрямо първоначалното съобщение:
   
   1. 
      Подписване на съобщението от ЕСОЕД (вкл. таймстамп)
      
   2. 
      Изпраща се съобщението към комуникационния клиент на АИС на приемащия участник
      
   3. 
      Комуникационният клиент на приемащия участник го предава до съответната АИС
      
   4. 
      АИС на приемащия участник синхронно предава техническо потвърждение (съобщение от тип DocumentReceipt) до своя комуникационен клиент
      
   5. 
      Това потвърждение по обратния ред аналогично се изпраща до АИС на изпращащия участник, като същата тази АИС не предава съобщение за потвърждение, че е получил DocumentReceipt с цел избягване на безкрайни цикли (технически на ниво SOAP протокол се потвърждава получаването на това съобщение.)
      

1.19Опит за пренос на невалиден документ

На диаграмата по-долу (Фиг. 4) е показан процес на пренос на един документ, при който по време на преноса възниква грешка при валидирането от ЕСОЕД. Това може да се случи поради много причини – неправилен XML, липсващ подпис на участник, изпращащият или получаващият участник не е регистриран в списъка на участниците и др.

Изключение от описания процес е, когато се получи съобщение от IP адрес, който не съвпада с нито един участник. В този случай ЕСОЕД просто връща SOAP грешка. Целта на това изключение е да не се претоварва ЕСОЕД с обработката и генерирането на отговор на съобщения, които пристигат от нерегистрирани IP адреси.

Фигура 4

Процесът се състои от няколко стъпки:

1. 
   АИС1 композира XML съобщение.
   
2. 
   АИС1 предава съобщението до КК1.
   
3. 
   АИС1 подписва XML съобщението чрез КК1 с неговия частен ключ, отговарящо на дефиницията в тази спецификация.
   
4. 
   АИС1 криптира съобщението чрез КК1 с публичния ключ на ЕСОЕД.
   

1. 
   Комуникационния клиент синхронно изпраща съобщението към ЕСОЕД
   
2. 
   ЕСОЕД извършва поредица дейности синхронно:
   

1. 
   Проверка на изпращащия участник в списъка на участниците по IP адрес
   
2. 
   Декриптиране на съобщението
   
3. 
   Проверка на схемата на полученото съобщение спрямо схемата на ЕСОЕД.
   
4. 
   Проверка на подпис на АИС1
   
5. 
   Проверка на синтактична структура на документа спрямо дефинициите в РИО
   
6. 
   Проверка на приемащия участник в списъка на участниците
   

3. 
   Една от горните проверки пропада и комуникационния сървър на ЕСОЕД генерира съобщение от тип EsoedError, което съдържа описание на грешката. Ако пропадне “a”, “b.”, “c.” или “d.” не се генерира обратно съобщение за грешка от тип EsoedError, а SOAP грешка.
   

1.20Опит за пренос, при който документът не може да се изпрати до АИС на приемащия участник

На диаграмата по-долу (Фиг. 5) е показан процес на пренос на един документ, при който по време на преноса възниква грешка при изпращането на едно съобщение до АИС на приемащия участник. За това може да има много причини – мрежови проблеми, АИС на приемащия участник не работи, АИС на приемащия участник не генерира коректно съобщение от тип DocumentReceipt и др.

Когато ЕСОЕД не може да изпрати по стандартния начин едно съобщение, то се преминава към резервен подход – изпращане на официалната електронна поща за съответното ведомство. Нейният адрес се взима от информацията за съответната АИС на участник в списъка с участници в ЕСОЕД.

Това означава, че грешката от ЕСОЕД в този случай съдържа код на грешка, който дефинира преминаване към резервен вариант – електронна поща.

В случай че ЕСОЕД има проблем с комуникацията до SMTP сървъра, който използва, тази информация се добавя към грешката, изпратена към АИС на изпращащия участник.

Фигура 5
Тук има няколко възможности за мястото, където може да възникне проблема:

• 
  При опит за изпращане до АИС на приемащия участник, няма връзка
  
• 
  При опит за изпращане до АИС на приемащия участник, тя връща техническа SOAP грешка
  
• 
  Върнатия DocumentReceipt от АИС на приемащия участник не е валиден
  
• 
  DocumentReceipt не може да се достави до АИС на изпращащия участник, което води до факта, че документът е получен в АИС на приемащия участник, но АИС на изпращащия участник не знае за това. Последният е доста особен и малко вероятен сценарий, но той може да доведе до това, че един документ е пренесен и обработен успешно от получателя, но подателя не знае за събитието.
  
• 
  По технически причини едно от изброените съобщения пристига два пъти до АИС.
  

1.21Генериране на съобщение за изтичане времето на сесия от комуникационния клиент

Най-честата причина за изтичане времето на сесия, без да се получи каквато и да е информация от ЕСОЕД, е прекъсване на връзката между КК и комуникационния сървър.

Разликата на този сценарий от другите е, че в този случай има съобщение, което се генерира не от комуникационния сървър, а от КК. Поради този факт, то не е подписано от ЕСОЕД, а с друг сертификат (сертификата на АИС, тъй като КК ползва него за тези операции).

Освен това има няколко важно особености:

• 
  За разлика от съобщенията за грешка EsoedError (които имат статус на електронни документи и се поддържат съгласно наредбите в регистър, съответно имат регистриран тип документ и генерирано УРИ), CCError са служебни съобщения, без тяло и УРИ.
  

Фигура 6

• 
  След генериране на съобщение CCError, по изискване на наредбата, КК ще отхвърля всякакви последвали съобщения по тази сесия (няма да ги доставя до АИС)
  

Каталог: upload -> docs
docs -> Задание за техническа поддръжка на информационни дейности, свързани с държавните зрелостни изпити (дзи) – учебна година 2012/2013
docs -> Наредба №2 от 10. 01. 2003 г за измерване на кораби, плаващи по вътрешните водни пътища
docs -> Наредба №15 от 28 септември 2004 Г. За предаване и приемане на отпадъци резултат от корабоплавателна дейност, и на остатъци от корабни товари
docs -> Общи положения
docs -> І. Административна услуга: Издаване на удостоверение за експлоатационна годност (уег) на пристанище или пристанищен терминал ІІ. Основание
docs -> I. Общи разпоредби Ч
docs -> Закон за изменение и допълнение на Закона за морските пространства, вътрешните водни пътища и пристанищата на Република България
docs -> Закон за предотвратяване и установяване на конфликт на интереси
docs -> Наредба за системите за движение, докладване и управление на трафика и информационно обслужване на корабоплаването в морските пространства на република българия

Изтегляне 0.53 Mb.

Сподели с приятели: