INTEROPERABILIDADE NA ADMINISTRAÇÃO PÚBLICA - iAP - … · Vantagens da utilização da GAP ......

Agência para a Modernização Administrativa, IP Rua Abranches Ferrão n.º 10, 3º G 1600-001 LISBOA

email: [email protected] | telefone: 21 723 12 00 | fax: 21 723 12 20 | www.ama.pt

INTEROPERABILIDADE NA ADMINISTRAÇÃO PÚBLICA

PROCEDIMENTOS PARA ADESÃO À iAP - PLATAFORMA DE INTEROPERABILIDADE DA ADMINISTRAÇÃO PÚBLICA

versão 3.0

Março de 2011

iAP

Guia Adesão iAP_v4_0.doc

Página 2 de 35

Índice

1. RESUMO EXECUTIVO .............................................................................................................................. 3

2. VISÃO GLOBAL ........................................................................................................................................ 4

3. PRÁTICAS DE REFERÊNCIA NO DOMÍNIO DA INTEROPERABILIDADE ........................................... 4

3.1. DEFINIÇÃO DE INTEROPERABILIDADE .................................................................................................... 4 3.2. ARQUITECTURA DE INTEGRAÇÃO .......................................................................................................... 4 3.3. ASPECTOS DA INTEROPERABILIDADE ABORDADOS PELA PLATAFORMA DE INTEROPERABILIDADE ............. 5

3.3.1. Principais normas técnicas utilizadas na Plataforma de Interoperabilidade .............................. 7

4. IAP - INTEROPERABILIADADE NA ADMINISTRAÇÃO PÚBLICA ........................................................ 8

4.1. PLATAFORMA DE INTEGRAÇÃO (PI) ....................................................................................................... 8 4.1.1. Vantagens da utilização da PI..................................................................................................... 8 4.1.2. Funcionalidades disponibilizadas na PI ................................................................................... 10 4.1.3. Serviços disponíveis na PI ........................................................................................................ 10 4.1.4. Requisitos Infra-estrutura para integração com a PI ................................................................ 11

4.1.4.1. Requisitos para ligação VPN ...................................................................................................................... 12 4.1.5. Requisitos da Plataforma Tecnológica das entidades aderentes à PI ....................................... 12 4.1.6. Requisitos de desenvolvimento do Serviço .............................................................................. 13 4.1.7. Processo de adesão à PI ............................................................................................................ 14

4.2. FORNECEDOR DE AUTENTICAÇÃO (FA) ............................................................................................... 16 4.2.1. Principais funcionalidades da utilização do FA ....................................................................... 16 4.2.2. Visão Geral do funcionamento do FA ...................................................................................... 17

4.2.2.1. Funcionamento do Single Sign-On (SSO) .................................................................................................... 21 4.2.3. Requisitos tecnológicos para utilização do FA ......................................................................... 22 4.2.4. Processo de adesão ao FA ......................................................................................................... 23

4.3. PLATAFORMA DE PAGAMENTOS DA ADMINISTRAÇÃO PÚBLICA (PPAP) ............................................... 24 4.3.1. Vantagens da utilização da PPAP............................................................................................. 25 4.3.2. Requisitos tecnológicos para utilização da PPAP ..................................................................... 25 4.3.3. Processo de adesão à PPAP ...................................................................................................... 25

4.4. GATEWAY DE SMS DA ADMINISTRAÇÃO PÚBLICA (GAP) ..................................................................... 26 4.4.1. Vantagens da utilização da GAP .............................................................................................. 27 4.4.2. Requisitos tecnológicos para utilização da GAP ...................................................................... 27 4.4.3. Processo de adesão à GAP ........................................................................................................ 28

5. MODELO DE SUSTENTABILIDADE DA IAP ......................................................................................... 28

5.1. MODELO DE SUSTENTABILIDADE DA PLATAFORMA DE INTEGRAÇÃO (PI) .............................................. 30 5.2. MODELO DE SUSTENTABILIDADE DO FORNECEDOR DE AUTENTICAÇÃO (FA) ........................................ 30 5.3. MODELO DE SUSTENTABILIDADE DA PLATAFORMA PAGAMENTOS DA ADMINISTRAÇÃO PÚBLICA (PPAP) 31 5.4. MODELO DE SUSTENTABILIDADE DA GATEWAY DE SMS DA ADMINISTRAÇÃO PÚBLICA (PPAP) ............ 31

6. CONCLUSÃO ........................................................................................................................................... 33

6.1. PRÓXIMOS PASSOS ............................................................................................................................... 34

7. REFERÊNCIAS ........................................................................................................................................ 35

iAP


Página 3 de 35

1. RESUMO EXECUTIVO

No contexto da modernização administrativa e da desmaterialização e melhoria contínua dos processos da

Administração Pública (AP), o presente documento identifica as normas que devem ser seguidas tendo em

vista a interoperabilidade técnica dos seus sistemas de informação e processos.

Assim, de forma a potenciar a disponibilização de serviços electrónicos integrados e transversais de acordo

com as necessidades do cidadão, é crescente a necessidade de comunicação e troca de informação electrónica

entre Entidades (tanto Públicas como Privadas). Tal coloca desafios de cariz técnico, funcional e

administrativo especialmente em iniciativas que se mostram transversais entre diferentes áreas da AP.

Para que esta necessidade seja colmatada de forma eficiente, mostra-se indispensável que tais iniciativas

sejam inseridas num contexto comum, onde sejam seguidos um conjunto de regras, normas e princípios

orientadores, de forma a garantir que todos os participantes possuem o mesmo suporte e uma base de

entendimento comum a nível técnico, processual e de negócio.

Com foco no serviço prestado pela AP ao seu cliente, o Cidadão/Empresa, foi definida e implementada a

Plataforma de Interoperabilidade da AP que visa proporcionar um método fácil e integrado de

disponibilização de serviços electrónicos transversais, tornando-se uma peça fundamental no processo de

modernização administrativa do Estado. Neste âmbito, são identificados os princípios orientadores:

Promover e facilitar a interoperabilidade na AP ao nível técnico, funcional e organizacional;

Agilizar e desenvolver a disponibilização de processos de negócio e de serviços electrónicos por parte

dos vários Organismos Públicos, com vista à simplificação administrativa interna e relacionamento

electrónico com terceiras entidades;

Permitir de forma fácil e integrada a disponibilização de serviços electrónicos transversais centrados

no Cidadão;

Facilitar e minimizar esforço e custo de desenvolvimento de novos processos electrónicos e

manutenção de serviços electrónicos já existentes;

Disponibilizar mecanismos de autenticação forte e gestão de identidade para, de uma forma segura,

facilitarem a identificação do Cidadão perante os Entidades que se encontram integradas na

Plataforma, com garantia de privacidade, confidencialidade e segurança dos dados.

Esta Plataforma de Interoperabilidade é baseada num conceito de disponibilização de serviços partilhados

entre diversas Entidades, com o intuito de simplificar a disponibilização destes serviços ao público.

iAP


Página 4 de 35

2. VISÃO GLOBAL

A necessidade de comunicação e troca de informação electrónica entre Entidades Públicas coloca desafios de

cariz técnico, funcional e administrativo especialmente em iniciativas que se mostram transversais entre

diferentes áreas da Administração Pública (AP). Para que esta necessidade seja colmatada de forma eficiente,

mostra-se indispensável que tais iniciativas sejam inseridas num contexto comum, onde sejam seguidos um

conjunto de regras, normas e princípios orientadores, de forma a garantir que todos os participantes possuem

o mesmo suporte e base de entendimento comum a nível técnico, processual e de negócio.

Ao invés de impor modelos únicos de organização e de sistemas de informação a toda a AP, é fundamental

tirar partido dos suportes tecnológicos que visem fomentar a utilização de um conjunto regras, padrões e

normas que permitam a eficaz e real utilização e reutilização de serviços electrónicos pelos actuais sistemas de

informação das Entidades da Administração Pública, implementando uma verdadeira Arquitectura Orientada

a Serviços, assente num orquestrador central: a Plataforma de Interoperabilidade da Administração Pública.

Esta Plataforma de Interoperabilidade é baseada num conceito de disponibilização de serviços partilhados

entre diversas Entidades Públicas, com o intuito de simplificar a integração entre os vários participantes.

3. PRÁTICAS DE REFERÊNCIA NO DOMÍNIO DA INTEROPERABILIDADE

3.1. Definição de Interoperabilidade

Interoperabilidade no âmbito das TIC pode ser definida como a capacidade de múltiplos sistemas trocarem e

reutilizarem informação sem custo de adaptação, preservando o seu significado.

A Interoperabilidade pode ser classificada a 3 níveis:

Interoperabilidade Técnica: capacidade de sistemas e dispositivos trocarem dados com fiabilidade e

sem custos acrescidos;

Interoperabilidade Semântica: capacidade de manter o significado da informação em circulação,

obtida pela utilização controlada de terminologias, taxionomias e esquemas de dados;

Interoperabilidade Organizativa: capacidade de cooperação entre organizações, obtida pela

compatibilização de processos, canais, motivações e outros elementos que facilitam a obtenção de fins

comuns.

3.2. Arquitectura de Integração

De modo a potenciar a utilização da capacidade de modelação de processos de negócio nos sistemas de

integração, as arquitecturas orientadas a serviços (SOA) definem um conjunto de melhores práticas neste

âmbito.

iAP


Página 5 de 35

As arquitecturas SOA colocam a prestação de serviços no centro do negócio, dando destaque à gestão de

serviços e à entidade a servir, ou seja, dando destaque ao negócio e não à tecnologia.

Neste tipo de arquitecturas as aplicações expõem funcionalidades de negócio como serviços que podem ser

acedidos por uma outra aplicação, interna ou externa à organização.

Os serviços disponibilizados devem ser utilizados como componentes para a criação de novas aplicações e

serviços, facilitando a criação e alteração de serviços e processos de negócio.

Para tal os serviços devem ser publicados num repositório comum e acessível aos consumidores, permitindo

obter a descrição e a definição do serviço, assim como o local onde o mesmo se encontra disponível.

Esta visão adoptada por Portugal está alinhada com a visão Europeia de Interoperabilidade, expressa na

Framework de Interoperabilidade Europeia (EIF – European Interoperability Framework).

A EIF, neste momento na versão 2.0, descreve a visão Europeia da Framework de Interoperabilidade,

apresentando um conjunto de guidelines e recomendações a adoptar pelos Estados Membros com vista à

construção de Plataformas tecnológicas destinadas a promover a interoperabilidade entre os diferentes

Sistemas de Informação dos Estados Membros e entre os diversos Sistemas de Informação do Estado tanto a

nível nacional com o local.

3.3. Aspectos da Interoperabilidade abordados pela Plataforma de Interoperabilidade

A Plataforma de Interoperabilidade foi desenvolvida como principal meio tecnológico de Integração

(Interoperabilidade Técnica) entre as Entidades Públicas Portuguesas (tanto a nível local como nacional) e

Europeias.

Foi construída seguindo as recomendações europeias da EIF e sobre normas abertas, amplamente testadas e

implementadas pelos principais fornecedores de SI.

Aborda igualmente a Interoperabilidade Semântica, proporcionando através do Modelo de Dados Canónico a

normalização de conceitos dentro da Plataforma e a disponibilização de um Catálogo de Serviços com o

conjunto de Serviços Canónicos que podem ser consumidos pelos SI com os quais integra.

Entende-se por Serviço Canónico, a representação e disponibilização de um serviço electrónico no Catálogo

de Serviços da Plataforma. Dado que é descrito em Modelo de Dados Canónico e possui meta dados de

contexto técnico e funcional, permitirá que outras Entidades tenham acesso aos dados necessários à sua

utilização e consumo

Cada Entidade que pretenda utilizar um serviço electrónico definirá o mapeamento entre o seu formato

interno (modelo de dados do seu SI) e o formato constante no Catálogo. A figura seguinte ilustra a descrição

anterior.

iAP


Página 6 de 35

Figura 1 – Normalização de dados na comunicação entre Entidades

As entidades Públicas deverão assim no seu modelo de referência de integração Inter-Organização para além

de contemplar os seus diversos Sistemas de Informação (SI), englobar a Plataforma de Interoperabilidade para

a comunicação entre as diversas Organizações.

Plataforma de Interoperabilidade da Administração Pública

SI - Organização

SI - Organização

SI - Organização

SI - Organização

SI - Organização

SI - Organização

SI - Organização

SI - Organização

SI - Organização

SI - Organização

SI - Organização

SI - Organização

SI - Organização

SI - Organização

SI - Organização

SI - Organização

SI - Organização

SI - Organização

Figura 2 – Modelo de referência para a integração entre organizações

A Interoperabilidade Organizativa está subjacente à Plataforma de Interoperabilidade na medida em que esta

fomenta uma mudança organizacional ao nível da disponibilização de serviços electrónicos dentro da AP

proporcionando um canal privilegiado de contacto e transferência de informação e contribuindo para a

quebra dos silos existentes dentro da AP.

iAP


Página 7 de 35

3.3.1. Principais normas técnicas utilizadas na Plataforma de Interoperabilidade

Apresenta-se na tabela seguinte as principais normas técnicas utilizadas pela Plataforma de

Interoperabilidade. O detalhe da sua utilização em cada um dos macro serviços apresenta-se nos capítulos

seguintes.

Designação Descrição Especificação

Hypertext Transfer Protocol Protocolo de comunicação de suporte Web HTTP

Hypertext Transfer Protocol Secure Protocolo de comunicação de suporte com

segurança Web HTTPS

Simple Object Acess Protocol Estrutura das mensagens trocadas e dos

mecanismos de tratamento Web SOAP

Web Services Description Language Linguagem baseada em XML para a

descrição de WebServices WSDL

Web Services Addressing Especificação para a comunicação da

informação de endereços entre WebServices

WS-

Addressing

Web Services Reliable Messaging Protocolo para a garantia de entrega de

mensagens na comunicação utilizando

WebServices

WS-RM

Web Services Security Segurança de integridade e confidencialidade

da comunicação Web WS-Security

Web Services Security with

Username Token Profile Segurança de autenticação da comunicação

Web

WS-Security

Username

Token Profile

Security Assertion Markup

Language

Standards para a troca de autenticações e

autorizações entre domínios de seguros SAML 2.0

Tabela 1 – Principais normas técnicas e protocolos utilizados na Plataforma de Interoperabilidade

iAP


Página 8 de 35

4. IAP - INTEROPERABILIADADE NA ADMINISTRAÇÃO PÚBLICA

A Plataforma de Interoperabilidade consiste numa plataforma central orientada a serviços e tem por objectivo

disponibilizar às Entidades da Administração Pública uma ferramenta partilhada para a interligação entre os

seus sistemas, composição e disponibilização de serviços electrónicos multicanal mais próximos das

necessidades do cidadão.

A Plataforma de Interoperabilidade disponibiliza 4 macro serviços independentes:

Plataforma de Integração (PI);

Fornecedor de Autenticação (FA);

Plataforma de Pagamentos da Administração Pública (PPAP);

Gateway de SMS da Administração Pública (GAP).

De seguida explica-se em detalhe cada um destes macro serviços e o modo de adesão.

4.1. Plataforma de Integração (PI)

A Plataforma de Integração (PI), anteriormente designada por Framework de Serviços Comuns, é uma

plataforma tecnológica central, orientada a serviços e baseada em standards e normas abertas, que visa dotar a

AP de uma ferramenta partilhada que permita a interligação dos diversos sistemas e a disponibilização de

serviços electrónicos multicanal.

4.1.1. Vantagens da utilização da PI

De entre os diversos benefícios que a utilização da Plataforma de Integração representa no processo de

integração de sistemas electrónicos Inter-Organizações, destacamos os seguintes:

Desacoplamento aplicacional – Permite minimizar as dependências de integração da Plataforma com

os vários participantes. Desta forma, cada sistema tem liberdade para evoluir de forma independente,

sem causar quebras de compatibilidade na integração já realizada;

Independência de suportes tecnológicos – A utilização de interfaces standards reduz e minimiza o

impacto na integração entre sistemas de diferente suporte tecnológico. Neste caso, a utilização de

protocolos de comunicação já massificados no mercado, é garante que este objectivo é atingido;

Simplicidade no processo de integração – Será sempre necessária a adaptação ao sistema a integrar

para que a integração seja efectuada de forma estável e segura. No entanto, ao integrar um sistema, a

equipa técnica responsável deve ver o esforço de desenvolvimento de integração minimizado, com o

uso de interfaces estáveis e de requisitos conhecidos;

Formato de dados compatível – Aplicações e sistemas integrados necessitam de acordo prévio entre o

formato de dados que trocam. A utilização de um modelo de dados comum permite a troca de

informação de forma sustentada, com possibilidade de evolução e utilização de extensões caso seja

necessário;

iAP


Página 9 de 35

Padrões de comunicação assíncronos – Em conjunto com a utilização de conceitos de persistência e

garantia de entrega de mensagens, este padrão de comunicação aumenta de sobremaneira a

segurança e fiabilidade de comunicação de mensagens, neutralizando os efeitos destabilizadores num

sistema com estas características, com especial incidência para falhas temporárias no canal de

comunicação (instabilidade de rede e infra-estrutura), bem como para o facto de permitir que sejam

trocadas mensagens com informação entre sistemas, mesmo quando o sistema de destino não se

encontre disponível;

Monitorização dos serviços – o BackOffice da iAP permite controlar as transacções e assegurar a

qualidade da informação necessária para a execução dos processos de forma facilitar o seu

processamento e evitar situações de erro. Permite ainda às entidades aderentes controlar a activação

ou inactivação dos serviços conforme as suas necessidades dos seus Sistemas de Informação;

Redução de custo de comunicações – a PI permite a adesão a um conjunto variado de Serviços

fornecidos por diversas Entidades através de um único ponto de acesso ao invés de diversas ligações

ponto a ponto o que minimiza os custos tanto das ligações como da sua manutenção e monitorização;

Existência de acordos de níveis de serviço (SLA’s) – na adesão à PI a AMA garante o cumprimento

dos SLA’s definidos que implicam a uma monitorização permanente e a assistência técnica efectuada

por equipa técnica dedicada

Apresenta-se de seguida um resumo das diferenças no processo de integração entre Sistemas de Informação

utilizando a PI e sem recorrer à utilização da PI

Figura 3 – Diferenças na integração entre SI recorrendo à PI e sem recorrer à PI

iAP


Página 10 de 35

4.1.2. Funcionalidades disponibilizadas na PI

A arquitectura da Plataforma de Interoperabilidade (mais particularmente da Plataforma de Integração) foi

concebida para garantir a máxima integração e interoperabilidade entre os diferentes sistemas das instituições

públicas, disponibilizando as seguintes funcionalidades:

Interface Web para administração e gestão da plataforma;

Gestão das Interfaces de WebServices e motor de integração efectuada através de configurações

realizadas pelos utilizadores das Organizações;

Conversão e transformação de formatos entre o modelo de entidades canónico e o modelo de

entidades da Organização e vice-versa, para a execução dos serviços que se encontram publicados na

Plataforma de Integração;

Federação de identidades, assegurando a conversão de identificadores não significativos (ou

identificadores opacos) conhecidos pela Plataforma de Integração para os identificadores relevantes

para as Organizações, designados de identificadores sectoriais, assegurando que nenhum sistema ou

entidade pública conhece as diferentes identidades dos Cidadãos e das Empresas;

Garante a segurança no transporte das mensagens, garantindo a autenticidade dos intervenientes na

comunicação e a cifra dos dados transmitidos;

Mecanismos de monitorização para o controlo e gestão de execução dos serviços;

Mecanismos de Mensagens, para a gestão das mensagens de execução dos serviços electrónicos.

4.1.3. Serviços disponíveis na PI

Na tabela seguinte apresentam-se uma listagem não exaustiva de serviços disponíveis na Plataforma de

Integração. A listagem de serviços completa encontra-se em:

http://www.iap.gov.pt/services/InteroperabilityPlatform/ServiceCatalog.aspx

Serviço Fornecedor Descrição

A Minha Rua AMA Permite a criação e consulta de pedidos efectuados ao serviço “A Minha Rua”.

SAM AMA Notificação de alteração de morada perante a Administração Pública.

FinancasObterDadosIRS DGCI/DGITA Fornecimento de dados do comprovativo de IRS

CESPedidoPessoaSingular IISS Descrição de um NISS singular incluindo Nome, data nascimento e local de Naturalidade

CESPedidoRendimento IISS Total de rendimentos colocados à disposição do beneficiário referentes a prestações sociais e subsídios de renda de casa

CESPedidoSituacaoContrib IISS Indica se o beneficiário possui dívidas para com a Segurança Social

iAP


Página 11 de 35


CESPedidoSituacaoPrestacional IISS Indica se o beneficiário possui débitos activos em conta corrente

Tabela 2 – Serviços disponíveis na Plataforma de Integração

Na tabela seguinte apresentam-se um conjunto de serviços a disponibilizar em 2011:


Indicação de Situação Tributária

DGCI/DGITA Indica se determinado contribuinte possui ou não dívidas ao fisco

Indicação de Estado de Actividade

DGCI/DGITA Indica se determinado contribuinte possui ou não actividade aberta

Prova de frequência escolar Min. Educação Indica se determinado aluno se encontra matriculado no ano lectivo.

Comprovativo de inscrição no Ensino Superior

DGES Indica se determinado aluno se encontra matriculado no ensino superior no ano lectivo.

Certidão de incapacidade multiusos

Min. Saúde Prova periódica da situação para cidadãos portadores de incapacidade

Informação da situação perante o emprego

IISS Informação relativa à situação perante o emprego

Tabela 3 – Serviços a disponibilizar em 2011 na Plataforma de Integração

Outros serviços poderão ser disponibilizados mediante pedido das Entidades aderentes e aceitação do

fornecimento dos dados por parte do detentor da informação (ver capitulo 4.1.7).

4.1.4. Requisitos Infra-estrutura para integração com a PI

De modo a garantir a segurança dos sistemas de informação aderentes e da informação que circula entre a PI e

as entidades aderentes actualmente existem dois modos de ligação:

Circuito dedicado: maior segurança, mais onerosa e mais adequadas para ligações que requerem

elevado volume de tráfego e garantia de qualidade de serviço. Se uma entidade aderente pretender

uma ligação dedicada terá que suportar os seus custos;

VPN sobre Internet: neste caso a segurança da informação é garantida via transmissão por canais

cifrados e autenticação dos pacotes que circulam, garantindo igualmente a integridade e privacidade

dos dados. Nesta ligação não é possível assegurar o nível de serviço (largura de banda), no entanto,

não implica investimento das entidades aderentes;

É igualmente necessário existirem regras de redes que permitam a comunicação entre os sistemas de

informação na Entidade e os sistemas da Plataforma de Interoperabilidade, para utilizando o protocolo HTTP.

A utilização de certificado digital para suporte a comunicação segura (HTTPS) é opcional.

iAP


Página 12 de 35

4.1.4.1. Requisitos para ligação VPN

Os requisitos necessários para a ligação VPN à Plataforma de Interoperabilidade são:

• Acesso à Internet, com largura de banda disponível suficiente para assegurar a ligação em boas

condições de funcionamento;

• Um endereço IP público, com conectividade para qualquer destino da Internet, para assegurar a

criação do túnel IPSec;

• Suporte de protocolos e funcionalidades no equipamento de estabelecimento da VPN, de acordo com

o definido em baixo:

SA de IKE (preferencial) SA de IKE (alternativa)

AES 256 bits SHA1

DH 5 Tempo de vida: 86400 segundos

3DES

SHA1

DH 2 Tempo de vida: 86400 segundos

SA de IPSec (preferencial) SA de IPSec (alternativa)

ESP (AES 256bits, MD5) Tempo de vida: 3600 segundos

ESP (3DES, MD5) Tempo de vida: 3600 segundos

O equipamento deverá suportar o envio de keepalives de Dead Peer Detection e deverá ter a capacidade de

manter e renegociar automaticamente as SAs de IPSec, mesmo na ausência de tráfego.

Os equipamentos deverão ainda ter capacidade para resolver os problemas de sobreposição de

endereçamento que poderão existir entre os diversos clientes no acesso aos servidores da AMA

(funcionalidade NAT – Network Address Translation).

4.1.5. Requisitos da Plataforma Tecnológica das entidades aderentes à PI

A Plataforma de Integração funciona baseado no modelo de comunicação assíncrono. As entidades devem ter

este modelo presente e devem assegurar os seguintes requisitos na sua arquitectura:

WebServices

o Representado via WSDL 1.1 (http://www.w3.org/TR/wsdl)

o Binding Soap 1.1 ou 1.2;

o XML document-style;

o Implementação assíncrona (one-way);

o Canal de transporte HTTP:

o Utilização opcional de HTTPS;

http://www.w3.org/TR/wsdl

iAP


Página 13 de 35

o Utilização opcional de autenticação http basic auth;

o WS-Addressing v1.0 (http://www.w3.org/TR/ws-addr-core/), como forma de

correlacionamento de mensagens em modelo de comunicação assíncrona;

Deve respeitar as recomendações WS-Interoperability Basic-Profile 1.1 (Interoperability Testing Tools 1.1 -

http://www.ws-i.org/deliverables/workinggroup.aspx?wg=testingtools);

4.1.6. Requisitos de desenvolvimento do Serviço

No âmbito de configuração de serviços e processos a serem integrados com a Plataforma de Integração, e de

acordo com as necessidades, será necessário que:

A Entidade disponibilize:

o WSDL do serviço a consumir pela Plataforma de Integração, respeitando as recomendações

WS-I BP 1.1;

o Caso a entidade pretenda que o serviço exposto ou consumido faça uso de um modelo de

dados especifico, necessitará de proceder à disponibilização desse Modelo de Dados (baseado

em XSD’s), bem como as regras de normalização entre ambos o modelos de dados canónico e

o modelo de dados especifico

o Estas regras serão baseadas em XSLT;

No caso de um serviço fornecido é necessário entregar à equipa da Plataforma de Interoperabilidade da

Administração Pública, o modelo de comunicação, análise funcional ou diagrama de sequência do processo

ao qual o serviço se encontra associado.

No que diz respeito à integração orientada a serviços são aqui incluídas as normas respeitantes aos Web

Sevices que devem ser suportadas pelas Entidades visadas. A norma XML é utilizada na especificação do Web

Service que é invocado para executar uma determinada tarefa ou um conjunto de tarefas e assim obter um

resultado específico.

O XML é usado como linguagem de base para a especificação dos principais padrões que estruturam os Web

Services:

WSDL – Web Service Description Language

SOAP – Simple Object Aplication Protocol

Nesse âmbito, a descrição de um Web Service é efectuada através de uma estrutura WSDL que contém os

detalhes de interacção que é possível estabelecer com o respectivo serviço. Esta descrição contém o formato

das mensagens trocadas e os respectivos protocolos de transporte. A comunicação entre os vários Web Services

e as entidades que os invocam é regrada pelo protocolo SOAP que descreve o seu modo de interacção.

http://www.w3.org/TR/ws-addr-core/

http://www.ws-i.org/deliverables/workinggroup.aspx?wg=testingtools

iAP


Página 14 de 35

A utilização do protocolo SOAP na Plataforma de Integração é suportada sobre transporte em HTTP (ou

HTTPS de forma opcional), que é um protocolo independente e compatível com qualquer servidor

aplicacional. A utilização de SOAP sobre HTTP possui ainda como vantagens o estabelecimento simplificado

a nível de regras de infra-estrutura em proxies e firewall, para além de ser actualmente considerado um

protocolo que é independente do tipo de plataforma ou de linguagem usado nos diferentes sistemas.

4.1.7. Processo de adesão à PI

Apresenta-se de seguida os passos necessários para adesão à PI para o consumo de um serviço

disponibilizado na PI. Este processo é válido mesmo para informações não disponíveis ainda na PI, sendo que

neste caso é necessário o desenvolvimento do serviço pela entidade fornecedora:

1. Escolha do serviço pretendido do catálogo de serviços disponíveis na PI;

2. Efectuar um pedido escrito à AMA (pode ser via e-mail para [email protected]) a indicar o(s) serviço(s) a

consumir, se possível uma estimativa do volume de invocações e o enquadramento legal para obter a

informação pretendida. No caso do serviço não estar ainda disponível na PI, é necessário indicar a

definição do serviço a desenvolver, a estimativa do volume de invocações e poderá ainda ser

necessário efectuar igualmente o pedido à entidade fornecedora da informação;

3. No caso de um serviço que não existe ainda na PI é necessário a definição do modelo de

sustentabilidade do serviço pela AMA, e a respectiva aceitação pela entidade consumidora. A

definição do modelo de sustentabilidade é efectuado de acordo com os critérios definidos no capítulo

5.1;

4. Caso se trate de dados pessoais deverá ser efectuado um pedido de autorização à Comissão Nacional

de Protecção de Dados (CNPD) para disponibilização dos dados à entidade consumidora. Este pedido

deverá ser acompanhado do Protocolo acordado entre as partes envolvidas;

5. Após aceitação do Protocolo é possível iniciar as operações técnicas de desenvolvimento do serviço:

a. Estabelecimento da ligação à Plataforma de Interoperabilidade (normalmente através da

criação de uma ligação VPN permanente);

b. Definição final dos requisitos e desenho do processo no caso de um novo serviço. Desta fase

resulta um documento acordado entre todas as partes envolvidas;

c. Adaptação dos sistemas de informação das entidades aderentes para integrar os dados da PI

d. Definição dos cenários de teste;

e. Caso o serviço ainda não esteja disponível é necessário o seu desenvolvimento pela entidade

fornecedora e a disponibilização do WSDL;

f. Desenvolvimento do serviço pela entidade consumidora e disponibilização do WSDL;

g. Aprovação dos WSDL;

iAP


Página 15 de 35

h. Instalação do serviço em ambiente de qualidade.

6. Testes integrados do serviço;

7. Instalação em produção;

8. Entrada em produção do serviço após validação de todos os requisitos técnicos, jurídicos e de

privacidade

De seguida apresentam-se os esquemas que ilustram estes passos. Os tempos apresentados são meramente

indicativos e reflectem tempos médios de execução das actividades.

Figura 4 – Esquema indicativo do fluxo do processo de adesão para um serviço existente na PI

iAP


Página 16 de 35

Figura 5 – Esquema indicativo do fluxo do processo de adesão para um serviço não existente na PI

4.2. Fornecedor de Autenticação (FA)

O Fornecedor de Autenticação permite a identificação electrónica unívoca de um utilizador portador do

Cartão de Cidadão nos Sistemas de Informação aderentes.

Assumindo-se como componente base para autenticação com Cartão de Cidadão a nível nacional e

internacional, a introdução das funcionalidades do Fornecedor de Autenticação permitem a normalização do

acto de autenticação electrónico para as Entidades que dele necessitem, com a possibilidade de transmissão de

informação adicional, devida e explicitamente autorizada pelo Cidadão.

Os atributos actualmente disponíveis incluem a devolução do Nome Completo do Cidadão, data de

nascimento, bem como as identificações sectoriais (NIC, NIF e NISS). Está em curso a análise e implementação

para devolução de atributos adicionais do cidadão tais como o NSNS, a fotografia, morada, filiação, etc.

4.2.1. Principais funcionalidades da utilização do FA

As principais funcionalidades e objectivos do Fornecedor de Autenticação são:

iAP


Página 17 de 35

Identificação sectorial com base no Cartão de Cidadão – Baseado na credenciação do Cidadão durante

a emissão do Cartão de Cidadão, aliado à Federação de Identidades da Plataforma de

Interoperabilidade da Administração Pública, o processo de autenticação no FA permite a

identificação sectorial e segura de um Cidadão;

Simplificação do processo de autenticação – O processo de autenticação do Cidadão pode ser

delegado ao FA, que será responsável por assegurar a validação de certificados, obtenção de atributos

qualificados, devolvendo os mesmos ao Organismo que solicitou o pedido de autenticação;

Segurança e normalização do processo de autenticação – Processo de autenticação será realizado com

os mesmos níveis de segurança e qualidade de serviço. É garantida a utilização da estrutura de chave

pública do Cartão, com recurso à validação OCSP (Online Certificate Status Protocol) dos certificados

de autenticação;

Single Sign-On (SSO) entre as diversas entidades aderentes: através do SSO é possível a navegação

entre os vários portais aderentes com fornecimento dos atributos necessários para autenticação e

garantia do nível de segurança proporcionado pelo FA

O Cidadão possui pleno conhecimento e opção sobre os dados a serem fornecidos – O Cidadão é

parte activa na transmissão de atributos aos Organismos que os solicitam. Para que a troca de

informação seja realizada, o Cidadão terá que dar a sua confirmação explícita.

Caso pretenda o Cidadão pode cancelar o processo de autenticação para a Entidade requisitante ou

bloquear a transmissão de atributos solicitados, mas não obrigatórios.

4.2.2. Visão Geral do funcionamento do FA

De seguida exemplifica-se, de forma sumária e transversal a utilização do FA com base num caso de uso de

autenticação de um Cidadão junto de um Organismo, ilustrando com imagens de sites que já o usam.

Fornecedor de Autenticação

Inte

rne

t

Sistemas de Suporte à Identificação

do Cidadão

Plataforma de

Interoperabilidade

Fornecedor de

Autenticação

Autenticação

com Cartão de

Cidadão

Serviços de validação do

Cartão de Cidadão

Entidade – Portal

institucional

Portal Web da Entidade

via web browserSmart Card Reader

Cidadão Nacional

(c/Cartão da Cidadão)

Circuito de autenticação

(sobre norma SAML)

Interacção entre sistemas

2

Interacção com utilizador

1

a

b

4 3

Fornecedor de

dados qualificados A

Fornecedor de

dados qualificados B

iAP


Página 18 de 35

Figura 6 – Diagrama explicativo do funcionamento do Fornecedor de Autenticação

No diagrama acima identificam-se as interacções que ocorrem durante o processo de autenticação através do

FA. A cada interacção identificada no diagrama (e representada por um número) indicam-se as acções

decorrentes ilustrando com um exemplo de acesso ao Portal do Cidadão (e por vezes do Portal da Estónia via

Stork):

1. Cidadão pretende aceder à área privada do portal de um Organismo (Portal do Cidadão), ao qual é

necessário que apresente a sua identidade;

Figura 7 – Escolha da autenticação com Cartão de Cidadão no Portal do Cidadão

2. Portal do Organismo (Portal do Cidadão) delega a autenticação e redirecciona o Cidadão para o

Fornecedor de Autenticação, juntamente com um pedido de autenticação assinado digitalmente;

Figura 8 – Indicação no FA dos atributos solicitados pelo Portal do Cidadão e pedido de autorização de

recolha desses atributos

iAP


Página 19 de 35

3. Cabe ao FA validar o pedido de autenticação recebido e solicitar a autenticação do Cidadão com

Cartão de Cidadão, através da inserção do PIN. Durante este processo, o FA irá efectuar as seguintes

operações internas:

a) Validação das credenciais do Cidadão com recurso à PKI do Cartão de Cidadão, via OCSP;

b) Obtenção de atributos que sejam solicitados, através dos vários fornecedores de atributos

qualificados, via Plataforma de Interoperabilidade. Este processo pode incluir a obtenção de

dados de outros Organismos (que podem ser obtidos via Federação de Identidades);

O FA apresenta a informação recolhida ao utilizador e pede que este autorize a sua transmissão. Deste

modo o cidadão tem total controlo sobre a informação transmitida.

Figura 9 – Janelas do navegador onde é solicitada a escolha do certificado de autenticação (deve ser escolhido

o do Cartão de Cidadão) e introdução do PIN

Figura 10 – O FA exibe ao Cidadão os atributos recolhidos e solicita autorização para transmissão dos mesmos

ao Portal de destino (nesta imagem mostra-se a autenticação no Portal da Estónia, onde são visíveis atributos

obrigatórios e facultativos). O Cidadão pode recusar a transmissão dos atributos solicitados (não sendo

possível a autenticação), ou recusar apenas a transmissão de atributos facultativos

iAP


Página 20 de 35

4. A identidade e atributos do Cidadão são validados e assinados digitalmente pelo FA, que

redireccionará o Cidadão de volta ao portal do Organismo (Portal do Cidadão). Cabe ao Organismo

(Portal do Cidadão) a validação e utilização dos mesmos.

Figura 11 – Área privada do Portal do Cidadão

Tanto no caso do Portal do Cidadão como no caso do Portal da Estónia para além de utilizar os dados do FA

para autenticação também os utiliza para pré-preenchimento do formulário de registo de utilizador.

Figura 12 – O Portal da Estónia aceita a autenticação fornecida pelo FA e também utiliza os atributos

fornecidos para registo do utilizador no seu Portal (este registo não é obrigatório mas sim uma opção dos

gestores do Portal da Estónia)

iAP


Página 21 de 35

4.2.2.1. Funcionamento do Single Sign-On (SSO)

De forma a assegurar a autenticação comum entre o Portal do Cidadão (ou outro Portal) e outros Portais onde

poderão residir os serviços e formulários electrónicos, as Entidades deverão ainda implementar

funcionalidades que permitam a utilização do Cartão de Cidadão como forma de autenticação simplificada

entre sites, numa lógica de single sign-on (SSO).

Após correcta autenticação Web por parte do Cidadão o FA manterá internamente, informação de que o

mesmo foi autenticado com sucesso. Torna-se assim possível a aplicação de uma lógica de SSO, demonstrada

na figura seguinte:


Inte

rnet

Portal do Cidadão


Cidadão



(sobre norma SAML)

2


1 4

3

Site Entidade

7

5

6

8

Portal Web da Entidade


Autenticação com Cartão de Cidadão

Site Entidade

Figura 13 – Explicação do funcionamento do SSO entre o Portal do Cidadão e o site/portal de outra entidade.

As mensagens 1 a 4 são similares às indicadas nas secções anteriores, sendo que as restantes têm por objectivo

a implementação do SSO. Utiliza-se o Portal do Cidadão como exemplo do Portal que inicia o fluxo de

autenticação:

5. Portal do Cidadão redirecciona para zona de acesso restrito no site da Entidade;

6. Durante a verificação de permissões de acesso à zona de acesso restrito, o portal da Entidade deve

verificar junto do FA, se o Cidadão já se encontra autenticado com o seu cartão de Cidadão:

Caso se encontre já autenticado, o Portal da Entidade deve redireccionar de forma automática, o

utilizador para o FA;

iAP


Página 22 de 35

Caso não tenha sido previamente autenticado, o Portal da Entidade pode dar a hipótese de efectuar

login local ou via FA, de acordo com a escolha do Cidadão;

7. O Fornecedor de Autenticação irá validar e reemitir uma credencial específica para o site da entidade e,

opcionalmente, solicita autenticação adicional do cidadão (e.g., caso estejam a ser solicitados dados

adicionais aos inicialmente disponibilizados).

8. Site de entidade valida credencial e autentica cidadão (e executa serviço electrónico).

4.2.3. Requisitos tecnológicos para utilização do FA

O formato de dados trocados entre o FA e o Organismo é baseado em SAML v2.0 (Security Assertion Markup

Language), de forma a assegurar a autenticidade e integridade de todas as transacções. SAML é um standard

XML que permite a troca de dados de autenticação e autorização em domínios Web de forma segura.

A utilização do SAML HTTP Post Binding associado ao SAML Web Browser SSO Profile permite que a

autenticação seja efectuada tecnicamente pelo browser do Cidadão, sem necessidade de ligação física entre os

Organismos e o FA.

As comunicações entre o Fornecedor de Autenticação e Organismo serão efectuadas sobre HTTP em canal

cifrado – Secure Socket Layer (SSL) ou Transport Layer Security(TLS). Esta comunicação será realizada sobre

Internet.

Fornecedor de

Autenticação (FA)Portal Web do Organismo

Pedido de Autenticação

Resposta de Autenticação

Figura 14 – Fluxo de mensagens entre o Portal da Entidade e o Fornecedor de Autenticação

O Fornecedor de Autenticação irá responder ao Organismo com informação autorizada pelo Cidadão. A

resposta inclui os atributos solicitados no pedido de autenticação. Esta ligação é também efectuada sobre

HTTP em canal cifrado – SSL ou TLS.

A utilização de canais cifrados, associado ao formato específico SAML garantirá que a troca de dados seguirá

as principais considerações:

Privacidade de dados – a utilização de canais cifrados garante que os dados do cidadão se mantêm

privados, impedindo a sua visualização por terceiros (ex. Visualização de dados por sniffer de rede);

Integridade de dados – o protocolo SAML, através de assinatura digital nos pedidos e respostas de

autenticação SAML, garante a integridade de dados de modificações não autorizadas (ex. Ataque por

Man-in-the Middle).

A utilização da autenticação pelo FA será efectuada somente através de ambiente Web e sobre Internet.

A imagem em baixo descreve as interacções entre o Portal do Organismo e o Fornecedor de Autenticação,

usando o browser do Cidadão como intermediário.

iAP


Página 23 de 35


Inte

rne

t Fornecedor de

Autenticação

Autenticação

com Cartão de

Cidadão

Entidade – Portal

institucional


Cidadão Nacional



(sobre norma SAML)

2


1 4 3

Portal Web da EntidadePortal Web da Entidade

Figura 15 – Interacção entre o Portal da Entidade e o Fornecedor de Autenticação

As adaptações a realizar pelo Organismo recaem fundamentalmente nos pontos 2 e 4, que correspondem

respectivamente à criação do pedido de autenticação SAML e no consumo da resposta proveniente do FA:

Pedido de autenticação - Corresponde ao pedido de identificação por parte do Organismo. Permitirá

reconhecer a origem do pedido, através da assinatura digital por um certificado digital x.509v3

associado ao Organismo. O pedido contém quais os atributos que devem ser obtidos (ex. NIF);

Resposta de autenticação – contém o resultado da autenticação efectuada pelo FA. Encontra-se na

resposta os atributos solicitados previamente pelo Organismo. Esta mensagem é assinada

digitalmente pelo FA de forma a garantir a integridade da informação.

A AMA dará todo o apoio técnico necessário para as entidades aderentes efectuarem o desenvolvimento da

autenticação via FA nos seus Sistemas de Informação, fornecendo inclusive exemplos das mensagens usadas

no processo de autenticação.

4.2.4. Processo de adesão ao FA

O processo de adesão ao FA é bastante simples e compõe-se dos seguintes passos (os tempos indicados para

cada tarefa são tempos médios e irão depender dos Sistemas de Informação das entidades aderentes):

1. Efectuar um pedido escrito à AMA (pode ser via e-mail para [email protected]) a indicar que pretende

aderir ao FA (e SSO);

iAP


Página 24 de 35

2. É efectuada pela AMA uma análise preliminar do pedido podendo ser necessário por parte da

entidade aderente o fornecimento de mais elementos relativos aos seus Sistemas de Informação e

Comunicação;

3. Adaptação dos sistemas de informação das entidades aderentes para delegação do processo de

autenticação no FA;

4. Desenvolvimento da funcionalidade de autenticação via FA (e SSO) (2 semanas);

5. Testes em o ambiente de testes e correcção de erros (1 semana);

6. Implementação em Produção tanto na entidade aderente como na AMA (4 dias);

7. Entrada em Produção.

Figura 16 – Esquema indicativo do fluxo do processo de adesão ao Fornecedor de Autenticação

4.3. Plataforma de Pagamentos da Administração Pública (PPAP)

Criada na lógica de serviços partilhados TIC, a PPAP é o sistema que permite aos organismos, disponibilizar

múltiplos métodos de pagamentos, para os diferentes canais de atendimento (sites/portais e balcões de

atendimento), despoletados a partir dos seus sistemas operacionais, garantindo a sua gestão, controlo e

monitorização integrada

Os métodos suportados pela PPAP são:

a. Cartão de Crédito (VISA, MasterCard e American Express);

b. Multibanco;

c. Pagamentos ao Estado;

d. Cheques;

e. Numerário;

f. Outros tipos de pagamentos (como Pré-pago e Pontos);

iAP


Página 25 de 35

4.3.1. Vantagens da utilização da PPAP

Visão e gestão integrada sobre os vários métodos de pagamentos disponibilizados para determinado

serviço on-line;

Plataforma suportada por standards abertos e seguros garantindo total independência da tecnologia

utilizada, sendo a integração com os sistemas operacionais efectuada através da utilização de

Webservices;

Tempo de implementação reduzido;

Redução de custos de investimento na:

o Aquisição de equipamentos e software;

o Implementação e configuração.

Redução de custos operacionais em administração, operação, help-desk e manutenção;

Através da utilização da validação por CheckDigit a referência Multibanco fica imediatamente

disponível para pagamento;

Dispensada toda a comunicação com a SIBS, dado que esta é efectuada entre a PPAP e a SIBS.

4.3.2. Requisitos tecnológicos para utilização da PPAP

A PPAP funciona através de Webservices numa arquitectura síncrona. Os Webservices podem ser suportados

por WSE 3.0 (“Web Services Enhancements”) ou WCF (Windows Communication Foundation). Poderão ser

igualmente desenvolvidos utilizando a tecnologia Java.

A AMA disponibiliza exemplos de projectos de integração em .NET e Java.

É necessária tal como para a integração com a Plataforma de Integração a existência de um circuito dedicado

ou uma VPN permanente sobre Internet tal como definido no ponto 4.1.4.1.

4.3.3. Processo de adesão à PPAP

O processo de adesão à PPAP é bastante simples e compõe-se dos seguintes passos (os tempos indicados para



aderir à PPAP;

2. Contratar junto das entidades fornecedoras dos métodos de pagamento (SIBS – Pagamento de

Serviços Multibanco e Redunicre para pagamento com cartões de crédito) o respectivo serviço;

iAP


Página 26 de 35

3. Assinatura do Protocolo de utilização da PPAP;

4. Adaptação dos sistemas de informação das entidades aderentes para utilização da PPAP;

5. Desenvolvimento da integração com a PPAP (1 semana);

6. Testes com o ambiente de testes e correcção de erros (1 semana);

7. Certificação da entidade junto da SIBS (1 semana)

8. Implementação em Produção (4 dias);


Figura 17 – Esquema indicativo do fluxo do processo de adesão à Plataforma de Pagamentos

4.4. Gateway de SMS da Administração Pública (GAP)

Criada na lógica de serviços partilhados TIC, a GAP é o sistema que permite o envio e recepção de SMS,

através de números curtos, entre os organismos da Administração Pública e os cidadãos.

A GAP permite serviços:

Informativos: envio de notificações para os subscritores;

Transaccionais: serviços que permitem uma interacção entre o utilizador e o sistema de informação

da entidade aderente. Tipicamente o utilizador envia uma mensagem e obtêm uma resposta

iAP


Página 27 de 35

Figura 18 – Esquema exemplificativo do funcionamento da GAP

4.4.1. Vantagens da utilização da GAP

Alargamento do número de canais de contacto disponíveis para a gestão do relacionamento com os

cidadãos;

Fácil integração com os sistemas operacionais dos organismos, através da reutilização dos

WebServices disponibilizados pela GAP;

Reencaminhamento de mensagens para os SI operacionais com base na sintaxe da mensagem;

Redução de custos de investimento na:

o Aquisição de equipamentos e software;

o Implementação e configuração.

Redução de custos operacionais em:

o Administração, operação, help-desk e manutenção;

o Menor custo dos SMS, dado que integra com as 3 operadoras móveis e devido ao volume de

mensagens da GAP existe um maior poder negocial junto das operadoras móveis.

4.4.2. Requisitos tecnológicos para utilização da GAP

A GAP funciona através de Webservices numa arquitectura síncrona. Os Webservices podem ser suportados

em tecnologia .NET ou Java tornando o sistema independente da Plataforma de desenvolvimento utilizada.

iAP


Página 28 de 35

É necessária tal como para a integração com a Plataforma de Integração a existência de um circuito dedicado

ou uma VPN permanente sobre Internet tal como definido no ponto 4.1.4.1.

4.4.3. Processo de adesão à GAP

O processo de adesão à GAP é bastante simples e compõe-se dos seguintes passos (os tempos indicados para



aderir à GAP;

2. Assinatura do Protocolo de utilização da GAP;

3. Adaptação dos sistemas de informação das entidades aderentes para utilização da GAP;

4. Desenvolvimento da integração com a GAP (3 dias);

5. Testes com o ambiente de testes e correcção de erros (4 dias);

6. Implementação em Produção (2 dias);


Figura 19 – Esquema indicativo do fluxo do processo de adesão à Gateway de SMS

5. MODELO DE SUSTENTABILIDADE DA IAP

A iAP assenta no modelo de sustentabilidade partilhada em que os seus custos de manutenção e evolução são

partilhados pelas entidades aderentes.

iAP


Página 29 de 35

Esta partilha de custos garante o cumprimento dos seguintes objectivos:

Assegurar um ambiente fiável e de alta disponibilidade que garanta a confiança dos utilizadores na

Plataforma;

Garantir elevados níveis de segurança tanto na identificação e autenticação de utilizadores como na

integridade e encriptação da informação transmitida;

Evolução da plataforma com a introdução de novas funcionalidades resultantes das necessidades dos

utilizadores;

Incorporação de actualizações tecnológicas que permitam manter o state of the art tecnológico que

pautou a concepção e construção da Plataforma;

Assegurar o cumprimento dos níveis de SLA’s acordados com os organismos da AP e com os

organismos privados, por vezes para aplicações críticas ao negócio, tanto ao nível da disponibilidade

do serviço como da manutenção correctiva.

Figura 20 – Factores que levam à criação do modelo de sustentabilidade

A definição do modelo de sustentabilidade pautou-se pelos princípios expostos no esquema seguinte:

iAP


Página 30 de 35

Figura 21 – Princípios do modelo de sustentabilidade da iAP

5.1. Modelo de Sustentabilidade da Plataforma de Integração (PI)

O objectivo do modelo de sustentabilidade para a Plataforma de Integração é que para um horizonte temporal

de 3 anos:

CtRt , em que

Rt - Receitas totais previstas para a Plataforma de Integração;

Ct - Custos totais associados ao funcionamento da Plataforma de Integração.

A imputação dos custos, associados à operação e funcionamento da Plataforma de Integração, a cada serviço é

efectuado de acordo com a sua:

• Complexidade (esforço de desenvolvimento e n.º de entidades envolvidas no serviço);

• Estimativa de utilização e (re) utilização;

• Número de entidades consumidoras;

Daqui resulta que cada serviço tem um custo associado, pelo que as entidades aderentes terão que contactar a

AMA para determinar o custo do serviço que pretendem consumir.

5.2. Modelo de Sustentabilidade do Fornecedor de Autenticação (FA)

Para os atributos actualmente disponibilizados (ver capítulo 4.2) a utilização do FA não tem custos associados.

iAP


Página 31 de 35

5.3. Modelo de Sustentabilidade da Plataforma Pagamentos da Administração Pública (PPAP)

O objectivo do modelo de sustentabilidade da PPAP é que as receitas decorrentes do custo de manutenção

cubram as despesas operacionais da PPAP que incluem:

Custos de manutenção evolutiva da Plataforma;

Correcções de anomalias;

Custos de comunicações;

Custos de licenciamento;

Etc.

Apresenta-se em baixo os custos associados à adesão e utilização da PPAP1:

Custo de configuração por

método de pagamento638 € (*)

Custo por pagamento (**)

até 12.000 pagamentos 0,120 €





Mais que 600.000 pagamentos 0,020 €

(*) – Valor revertível em pagamentos durante um ano a contar da data de configuração

(**) – O escalão para definição do custo por pagamento é definido tendo em conta a soma dos

pagamentos efectuados por todas as entidades activas da Instituição

5.4. Modelo de Sustentabilidade da Gateway de SMS da Administração Pública (PPAP)

O objectivo do modelo de sustentabilidade da GAP é que as receitas decorrentes do custo de manutenção

cubram as despesas operacionais da GAP que incluem:

Custos de manutenção evolutiva da Plataforma;

Correcções de anomalias;

Custos de comunicações;

Custos de licenciamento;

1 Aos custos apresentados acresce IVA à taxa legal em vigor

iAP


Página 32 de 35

Etc.

O custo de manutenção dispendido pelos organismos aderentes à Gateway de SMS resulta da aplicação das

seguintes condições2:

1. Custo de configuração do originador (Sistema de informação de envio/recepção de SMS) de 206 €,

valor este que será descontado ao custo de manutenção no primeiro ano, a contar da respectiva data

de contratualização do Originador e de acordo com o valor do custo de manutenção por SMS enviado

e recebido;

2. Mensalmente o montante resultante da aplicação do preçário em vigor aplicado ao Custo por SMS

recebido ou enviado utilizando o respectivo SMS-Center dos operadores de telecomunicações móveis:

3. Anualmente o montante resultante da aplicação do custo de manutenção ao número de SMS enviados

e recebidos nos 12 meses anteriores, conforme o seguinte preçário:

2 Aos custos apresentados acresce IVA à taxa legal em vigor

iAP


Página 33 de 35

6. CONCLUSÃO

Portugal tem feito um enorme esforço na área de e-GOV. O nono Benchmark sobre governo electrónico de

Dezembro de 2010, divulgado pela Comissão Europeia, coloca Portugal acima da média Europeia atingindo a

pontuação máxima nos indicadores escolhidos. Este relatório está disponível em:

http://ec.europa.eu/information_society/newsroom/cf/item-detail-dae.cfm?item_id=6537

Este guião tem por objectivo auxiliar todas as entidades públicas (tanto centrais como locais) na área de e-

GOV, nomeadamente na áreas de eID e Interoperabilidade, apresentando as normas técnicas que devem ser

seguidas pelos organismos públicos na interacção com a iAP. Estas normas, baseadas em standards abertos e

comummente suportados pelas plataformas tecnológicas, visam assegurar a possibilidade de integração

electrónica dos sistemas de informação da Administração Pública, tendo em vista a prestação de um melhor,

mais integrado, eficaz e económico serviço público.

Neste momento a iAP é uma realidade, um caso de sucesso e um exemplo a seguir por outros países

europeus, apresentando-se assim, como uma peça central na estratégia de Modernização Administrativa,

tendo em vista a implementação de uma arquitectura orientada a serviços por parte da Administração

Publica, contribuindo para a:

Melhoria da eficiência, designadamente com:

o Simplificação/automatização processual e administrativa, reduzindo tempos de atendimento

e processamento;

o Aumento da celeridade e disponibilidade da informação;

o Aumento da qualidade/certificação da informação, podendo contribuir para a redução de

custos associados a processos diversos despoletados pela má qualidade da informação;

o Melhoria da experiência para o cidadão, resultante da maior comodidade (minimização de

interacções e de dados a fornecer) e rapidez de cada interacção.

Melhoria da eficácia e/ou qualidade dos serviços, designadamente com:

o Melhoria da experiência para o cliente, resultante da maior comodidade (minimização de

interacções e de dados a fornecer) e rapidez de cada interacção;

o Aumento da transparência e segurança das transacções;

o Reforço de imagem inovadora por parte da Administração Pública Portuguesa;

Redução de Custos nomeadamente através:

o Capacidade de reutilização de serviços por todos os organismos da Administração Pública;

o Disponibilização de ferramentas que agilizam a implementação de novos serviços;

http://ec.europa.eu/information_society/newsroom/cf/item-detail-dae.cfm?item_id=6537

iAP


Página 34 de 35

o Redução de custos de Manutenção e evolução de serviços que passam a poder ser

implementados uma única vez para toda a Administração Publica e entregues em diferentes

formatos e versões de acordo com a especificidade de cada organismo;

o Redução das necessidades de comunicações “muitos-para-muitos”, pela ligação à Plataforma

de Interoperabilidade uma só vez, possibilitando a interacção com todos os organismos

públicos.

6.1. Próximos passos

A iAP irá continuar a evoluir garantido uma ferramenta para disponibilização de serviços electrónicos sempre

actual, pronta a responder aos desafios de uma AP moderna e focada no Cidadão.

Assim em breve irá ser disponibilizada uma ferramenta de gestão de formulários de modo a permitir a fácil

desmaterialização de serviços para entidades cujo volume não justifica um avultado investimento numa

ferramenta desta natureza.

De igual modo abrangendo a iniciativa do Cartão de Cidadão (CC) está em curso um projecto que irá permitir

a Certificação de Atributos Profissionais através do CC.

Irão ser disponibilizados mais atributos no FA quer através do projecto de Certificação de Atributos

Profissionais, quer outros atributos relevantes para autenticação e execução dos serviços online.

No âmbito da integração de SI, mais serviços irão ficar disponíveis, o BackOffice está a ser melhorado de

modo a permitir um maior, melhor e mais fácil controlo (para as entidades aderentes) sobre os serviços

fornecidos e consumidos.

iAP


Página 35 de 35

7. REFERÊNCIAS

Na tabela seguinte são apresentadas as referências para as Normas e Recomendações enunciadas.

Especificação Descrição Referências

HTTP Protocolo de comunicação de

suporte Web http://www.ietf.org/rfc/rfc2616.txt

HTTPS Protocolo de comunicação de

suporte com segurança Web http://www.ietf.org/rfc/rfc2818.txt

SOAP

Estrutura das mensagens

trocadas e dos mecanismos de

tratamento Web

http://www.w3.org/TR/soap12-part1/

WSDL Linguagem baseada em XML

para a descrição de WebServices http://www.w3.org/TR/wsdl

WS-Addressing

Especificação para a

comunicação da informação de

endereços entre WebServices

http://www.w3.org/Submission/ws-addressing/

WS-RM

Protocolo para a garantia de

entrega de mensagens na

comunicação utilizando

WebServices

http://www.oasis-

open.org/committees/tc_home.php?wg_abbrev=ws

rm

WS-Security

Segurança de integridade e

confidencialidade da

comunicação Web

http://www.oasis-

open.org/committees/tc_home.php?wg_abbrev=ws

s

http://docs.oasis-open.org/ws-sx/ws-

securitypolicy/v1.2/ws-securitypolicy.html

Request-Reply

Messaging

Padrões de comunicação

síncrona http://www.eaipatterns.com/index.html

One-Way

Messaging

Padrões de comunicação

assíncrona http://www.eaipatterns.com/index.html

SAML Token

Profile

Standards para a troca de

autenticações e autorizações

entre domínios de seguros

http://www.oasis-

open.org/committees/tc_home.php?wg_abbrev=sec

urity

http://www.ietf.org/rfc/rfc2616.txt

http://www.ietf.org/rfc/rfc2818.txt

http://www.w3.org/TR/soap12-part1/

http://www.w3.org/TR/wsdl

http://www.w3.org/Submission/ws-addressing/

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrm



http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss



http://docs.oasis-open.org/ws-sx/ws-securitypolicy/v1.2/ws-securitypolicy.html

http://docs.oasis-open.org/ws-sx/ws-securitypolicy/v1.2/ws-securitypolicy.html

http://www.eaipatterns.com/index.html

http://www.eaipatterns.com/index.html

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security



INTEROPERABILIDADE NA ADMINISTRAÇÃO PÚBLICA - iAP - … · Vantagens da utilização da GAP ......

Documents

Transcript of INTEROPERABILIDADE NA ADMINISTRAÇÃO PÚBLICA - iAP - … · Vantagens da utilização da GAP ......