Предложение за изпълнение на поръчката


Общи изисквания за реализиране на клиентски интеграции с програмни интерфейси (APIs) на други / външни АИС



страница6/38
Дата17.06.2017
Размер4.56 Mb.
#23756
1   2   3   4   5   6   7   8   9   ...   38

Общи изисквания за реализиране на клиентски интеграции с програмни интерфейси (APIs) на други / външни АИС

Общи изисквания за реализиране на клиентски интеграции с програмни интерфейси (APIs) на други / външни АИС



Трябва да бъде реализирана клиентска интеграция между ИСЦЕИ и програмните интерфейси (APIs) на РО, обслужваща като минимум процесите описани в т. Error: Reference source not found от ТС с цел идентифициране на лица в качеството им на пълномощници за дадена услуга.






Трябва да бъде реализирана клиентска интеграция между ИСЦЕИ и Подсистемата за автоматични нотификации (ПАН), чрез програмния интерфейс (API) на ПАН






Трябва да бъде реализирана клиентска интеграция между ИСЦЕИ и "Журнал на събитията" (ПЖС), чрез програмния интерфейс (API) на ПЖС.







Изисквания за реализиране на проверка на удостоверение за електронна идентичност

Изисквания за реализиране на проверка на удостоверение за електронна идентичност



Трябва да бъде реализирана функционалност за проверка на удостоверенията за електронна идентичност, която трябва да включва:

  • Проверка на съответствието на структурата на удостоверението със стандарта X.509;

  • Проверка за цялостност, непроменливост и интегритет на съдържанието на удостоверението;

  • Проверка на валидността на удостоверението чрез проверка на удостоверителната му верига, срока му на действие и неговия статус в съответния списък с прекратени удостоверения.






Съгласно ППЗЕИ, ИСЦЕИ трябва да поддържа OpenID Connect 1.0 за обмен на автентикационна информация






Методът за автентификация при използване на OpenID Connect 1.0 трябва да бъде private_key_jwt






Изпълнителят трябва да предложи OpenID обектите, за които е целесъобразно добавянето на HMAC защита с оглед подобряване на сигурността при евентуално компрометиране на системните генератори за случайни числа и минимизиране на възможностите за претоварване на системните ресурси при заявки в бази данни/кеш






Изпълнителят трябва да извърши сертификация на имплементацията в ИСЦЕИ в OpenID Foundation за своя сметка






Съгласно ППЗЕИ ИСЦЕИ трябва да поддържа SAML 2.0 за обмен на автентикационна информация






За ИСЦЕИ Изпълнителят трябва да създаде (и опционално регистрира в IANA) Level-of-Assurance (LoA) идентификатор съгласно дефинираните такива в Регламент 910/2014, и съответен профил за автентикация с еИД.






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

  • ИСЦЕИ трябва да поддържа и услуги / процес по проверка на идентичност при вход в информационна система от страна на служител на администрация / длъжностно лице / гражданин в служебно качество.

  • ИСЦЕИ трябва да поддържа заявки за проверка на електронна идентичност, които съдържат задължителен параметър, подаден от АИС на ДЕАУ или друг държавен орган, с който се указва, че идентификацията е за лице в неговото служебно качество.






Използване на мобилно устройство като четец за носител на УЕИ:

  • ИСЦЕИ трябва да поддържа проверка на електронна идентичност извършена и с участието на мобилно устройство по реда на чл. 20, ал. 2 от ПП ЗЕИ.

  • Изпълнителят трябва да предложи и реализира протокол и процес за идентификация с участието на мобилно устройство.






Използване на мобилно устройство или друг метод за многофакторна автентикация:

  • ИСЦЕИ трябва да поддържа опционален режим с двуфакторна автентикация - например чрез специфична функционалност на Мобилното приложение за граждани (МПГ)

Режимът за двуфакторна автентикация трябва да може да се конфигурира като "задължителен" за:

  • конкретни ЕАУ, групи от ЕАУ или ДЕАУ

  • по искане на ДЕАУ (възможност да се конфигурира през ПДЕАУ)

  • по искане на гражданин (възможност да се конфигурира в ПГ)

  • конкретен идентификатор на гражданин и/или отделни УЕИ на гражданин:

  • по желание на гражданин (възможност да се конфигурира в ПГ).







Изисквания за реализиране на трансгранична електронна идентификация (eIDAS)

Изисквания за реализиране на трансгранична електронна идентификация (eIDAS)



ЦЕИ трябва да бъде напълно функционално национално звено за трансгранична електронна идентификация. ИСЦЕИ трябва да реализира техническите изисквания за осъществяване на трансгранична електронна идентификация, съгласно Регламент (ЕС) 910/2014 (по-известен като eIDAS), и подзаконовата му нормативна уредба, в които са дефинирани изисквания за реализиране на трансгранична електронна идентификация в рамките на ЕС:

(https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/eID+eIDAS+profile).








Участникът да разгледа и анализира пилотните проекти STORK 2.0 (https://www.eid-stork2.eu) за това кои компоненти могат да бъдат преизползвани при изпълнението на настоящата обществена поръчка.






Участникът да се запознае, прегледа и анализира eIDAS Building Blocks и по-специално eIDAS Node

(https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/eIDAS-Node) кои компоненти могат да бъдат преизползвани при изпълнението на настоящата обществена поръчка.








Тъй като eIDAS предполага използването единствено на SAML 2.0, трябва да бъде анализира нуждата от транслиране на съобщенията между SAML 2.0 и OpenID Connect 1.0 при трансгранична електронна идентификация и нуждата от разработка на прокси-услуга за транслиране на заявките. При идентифициране на такава нужда, трябва да бъде реализирана необходимата функционалност в ИСЦЕИ, която да позволява транслиране на съобщения и да осигурява оперативна съвместимост с eIDAS.







Изисквания за реализиране на поддръжка на СеИД

Изисквания за реализиране на поддръжка на СеИД



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






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







Изисквания за реализиране на функционалност за предоставяне на данни / обстоятелства

Изисквания за реализиране на функционалност за предоставяне на данни / обстоятелства



ИСЦЕИ трябва да поддържа приемане на заявки и връщане на отговори на атомични въпроси за обстоятелства (потвърждаване или отхвърляне на обстоятелства), чрез проверки в реално време, чрез клиентска интеграция с външни програмни интерфейси (APIs), като минимум на външните регистри, описани в т. Error: Reference source not found от ТС.






ИСЦЕИ трябва да поддържа предоставяне на конкретни данни, които са допустими според структурираното описание на личните данни в ИИСДА, съответно необходими и нормативно изискуеми, за предоставянето на съответната административна услуга. Данните трябва да се извличат в реално време от автентични първични източници, чрез клиентска интеграция с външни програмни интерфейси (APIs), като минимум на външните регистри, описани в т. Error: Reference source not found от ТС.






ИСЦЕИ трябва да поддържа вътрешен регистър / списък / номенклатура със структурирани описания на услуги, като за всяка вписана услуга, трябва да може да се избират от номенклатура за допустими действия и обем на представителна власт, за нуждите на Регистъра на овластяванията (РО).






ИСЦЕИ трябва да поддържа вътрешен регистър / списък / номенклатура, за дефиниране от номенклатура, дефинираща допустими действия и обем на представителна власт, за нуждите на Регистъра на овластяванията (РО). ИСЦЕИ трябва да може да поддържа отделна номенклатура за всеки ДЕАУ, регистриран като клиент на ЦЕИ.






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







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

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



Съгласно ЗЕИ, частно-правни субекти могат да използват услугите на държавния ЦЕИ, за което дължат такса.

Трябва да бъде разработена функционалност за:



  • регистриране на броя заявки от даден ДЕАУ / група ДЕАУ

  • калкулиране на дължима сума по тарифа за услуги

  • генериране и изпращане на фактури

  • предоставяне на възможност за електронно плащане, вкл. чрез абонамент (напр. еднократно въвеждане на детайли от кредитна карта и автоматично изтегляне на съответната месечна сума).






ИСЦЕИ трябва да поддържа функционалност за регистриране на броя на заявките от ДЕАУ






ИСЦЕИ трябва да поддържа функционалност за лимитиране на броя на заявките приемани от ДЕАУ за единица време (секунда / час / ден / месец).






ИСЦЕИ трябва да поддържа номенклатура на цените на предоставяните услуги, с възможност за диференциране на стойностите спрямо група доставчици на услуги и брой заявки






ИСЦЕИ трябва да предоставя справочна информация за обема на потреблението по доставчици и групи доставчици






ИСЦЕИ трябва да предоставя детайлна и обобщена финансова информация на базата на номенклатурата на цените (тарифа) и обема заявки






ИСЦЕИ трябва да генерира електронни фактури на базата на потреблението към доставчиците на услуги. Електронните фактури трябва да могат да се извличат в машинно четим вид за зареждане в счетоводен софтуер, както и да могат да бъдат разпечатвани на хартиен носител.






ИСЦЕИ трябва да поддържа механизъм за дефиниране на прагове за генериране на автоматични нотификации при чувствително увеличение на броя на заявките на базата на достигане на абсолютни стойности и процентна разлика спрямо предходен период - ден, седмица, месец






Справочната функционалност трябва да бъде достъпна както за служителите, обслужващи ИСЦЕИ, така и за ДЕАУ в реално време






ИСЦЕИ трябва да визуализира информация за поисканите от ДЕАУ данни






ИСЦЕИ трябва да реализира механизъм за отказ от страна на гражданите за предоставяне на данни






Трябва да бъде разработена детайлна справочна функционалност, както и функционалност за генериране на нотификации през Подсистемата за автоматични нотификации (ПАН) за необичайно висока активност, която може да се отрази на заплатената цена.






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







Изисквания за електронните идентификатори и секторните електронни идентификатори

Изисквания за електронните идентификатори и секторните електронни идентификатори



При идентификация, освен Token/Assertion, ИСЦЕИ трябва да върне на доставчика на услугата уникален идентификатор на идентифицирания гражданин, който той да запише в своята база данни и чрез който да идентифицира последващи влизания на същия гражданин. В зависимост от бизнес изискванията, този идентификатор може да бъде електронния идентификатор, по смисъла на Закона за електронната идентификация, ЕГН или секторен електронен идентификатор (по смисъла на същия закон).






Секторните електронни идентификатори трябва да бъдат формирани на база на електронния идентификатор и на база на секторен ключ, по начин, който не позволява възстановяването на оригиналния електронен идентификатор. Това може да стане например чрез използване на криптографска hash функция, приложена например върху конкатенацията eID + sectorKey + salt, където секторният ключ се получава от всеки Доставчик на услуги в административния панел, а salt е уникален случайно генериран низ за всеки гражданин. Секторният електронен идентификатор се генерира всеки път и не се съхранява в ИСЦЕИ.






Трябва да бъде реализиран метод за генериране на секторни електронни идентификатори съгласно най-актуалните добри практики към момента на изпълнение на обществената поръчка.






Всеки частно-правен субект представлява отделен сектор и трябва да бъде третиран като такъв.







Изисквания за реализиране на програмен интерфейс (API) на ИСЦЕИ за атомични заявки

Изисквания за реализиране на програмен интерфейс (API) на ИСЦЕИ за атомични заявки



Трябва да бъде реализиран програмен интерфейс (API) към ИСЦЕИ, който трябва да поддържа автоматизирани отговори на атомични запитвания относно обстоятелства, вписани в първични регистри, интегрирани с ИСЦЕИ.






Допустими атомични запитвания, респективно - отговори за потвърждаване или отхвърляне на обстоятелства, без да се разкрива същинската стойност на данната са например такива, които са свързани с потвърждаване на възраст, адрес, гражданство и др. Примерни въпроси: “Лицето има ли навършени 18 години?”, “Настоящият адрес на лицето в гр. Пловдив ли е?”, “Лицето има ли българско гражданство?”.






Програмният интерфейс (API) трябва да отговаря и на общите технически и функционални изисквания за реализиране на програмни интерфейси (APIs), съгласно т. Error: Reference source not found от ТС.







Изисквания за реализиране на програмен интерфейс (API) за удостоверяване на данни от първични регистри

Изисквания за реализиране на програмен интерфейс (API) за удостоверяване на данни от първични регистри



Трябва да бъде реализиран програмен интерфейс (API) към ИСЦЕИ, който трябва да поддържа автоматизирани отговори на запитвания за получаване на автентични данни, относно обстоятелства, вписани в първични регистри, интегрирани с ИСЦЕИ.






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






Програмният интерфейс (API) трябва да отговаря и на общите технически и функционални изисквания за реализиране на програмни интерфейси (APIs), съгласно т. Error: Reference source not found от ТС.







Изисквания за реализиране на програмен интерфейс (API) на ИСЦЕИ

Изисквания за реализиране на програмен интерфейс (API) на ИСЦЕИ



Трябва да бъде реализиран програмен интерфейс (API) за автоматизиран междусистемен достъп до услугите, функционалностите и данните на ИСЦЕИ.






Услугите и функционалностите на програмния интерфейс (API) трябва да бъдат съобразени и разработени така, че като минимум да се посрещнат нуждите на порталите, информационните системи, подсистемите и модулите, за които е предвиден достъп, съгласно изискванията в настоящата ТС.






Програмния интерфейс (API) на ИСЦЕИ трябва да реализира стриктна схема, при която външни АИС, които са интегрирани с ИСЦЕИ и заявяват проверка за електронна идентичност при вход в системата на свои служители, трябва задължително да подават параметър в заявката за идентификация, с който експлицитно се определя, в какво качество се идентифицира съответния потребител в АИС:

  • гражданин в лично качество

  • гражданин в служебно качество






Програмният интерфейс (API) трябва да отговаря и на общите технически и функционални изисквания за реализиране на програмни интерфейси (APIs), съгласно т. Error: Reference source not found от ТС.







Каталог: rdonlyres
rdonlyres -> Областна дирекция на мвр – р а з г р а д районно управление на мвр – р а з г р а д
rdonlyres -> Република българия министерство на вътрешните работи а н а л и з
rdonlyres -> Стара Загора Дата Време
rdonlyres -> „развитие на човешките ресурси” Ч
rdonlyres -> Дипломна работа за получаване на образователно-квалификационна степен „Магистър" по специалността „Стратегическо ръководство и управление на сигурността и обществения ред"
rdonlyres -> Наредба за условията и реда за функциониране на националната система за ранно предупреждение и оповестяване на органите на изпълнителната власт и населението при бедствия и за оповестяване при въздушна опасност
rdonlyres -> Решение за откриване на процедура за възлагане на обществена поръчка
rdonlyres -> Закон за движението по пътищата в сила от 01. 09. 1999 г. Отразена деноминацията от 05. 07. 1999 г
rdonlyres -> Наредба №8121з-968 от 10 декември 2014 Г. За правилата и нормите за пожарна безопасност при извършване на дейности в земеделските земи


Сподели с приятели:
1   2   3   4   5   6   7   8   9   ...   38




©obuch.info 2024
отнасят до администрацията

    Начална страница