interoperabilidade na administração pública

Transcrição

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
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
iAP
Í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.
5.2.
5.3.
5.4.
6.
CONCLUSÃO ........................................................................................................................................... 33
6.1.
7.
MODELO DE SUSTENTABILIDADE DA PLATAFORMA DE INTEGRAÇÃO (PI) .............................................. 30
MODELO DE SUSTENTABILIDADE DO FORNECEDOR DE AUTENTICAÇÃO (FA) ........................................ 30
MODELO DE SUSTENTABILIDADE DA PLATAFORMA PAGAMENTOS DA ADMINISTRAÇÃO PÚBLICA (PPAP)
31
MODELO DE SUSTENTABILIDADE DA GATEWAY DE SMS DA ADMINISTRAÇÃO PÚBLICA (PPAP) ............ 31
PRÓXIMOS PASSOS............................................................................................................................... 34
REFERÊNCIAS ........................................................................................................................................ 35
Guia Adesão iAP_v4_0.doc
Página 2 de 35
iAP
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.
Página 3 de 35
iAP
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:
3.2.

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.
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.
Página 4 de 35
iAP
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.
Página 5 de 35
iAP
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.
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
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
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.
Página 6 de 35
iAP
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
Web Services Reliable Messaging
Protocolo para a garantia de entrega de
mensagens na comunicação utilizando
WebServices
Web Services Security
Web Services Security with
Username Token Profile
Security Assertion Markup
Language
WSAddressing
WS-RM
Segurança de integridade e confidencialidade
da comunicação Web
WS-Security
Segurança de autenticação da comunicação
Web
WS-Security
Username
Token Profile
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
Página 7 de 35
iAP
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;
Página 8 de 35
iAP

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
Página 9 de 35
iAP
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
SAM
AMA
FinancasObterDadosIRS
CESPedidoPessoaSingular
DGCI/DGITA
IISS
CESPedidoRendimento
IISS
CESPedidoSituacaoContrib
IISS
Permite a criação e consulta de pedidos efectuados ao
serviço “A Minha Rua”.
Notificação de alteração de morada perante a
Administração Pública.
Fornecimento de dados do comprovativo de IRS
Descrição de um NISS singular incluindo Nome, data
nascimento e local de Naturalidade
Total de rendimentos colocados à disposição do
beneficiário referentes a prestações sociais e
subsídios de renda de casa
Indica se o beneficiário possui dívidas para com a
Segurança Social
Página 10 de 35
iAP
Serviço
CESPedidoSituacaoPrestacional
Fornecedor
IISS
Descrição
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:
Serviço
Fornecedor
Indicação de Situação
Tributária
Indicação de Estado de
Actividade
Prova de frequência escolar
DGCI/DGITA
Comprovativo de inscrição no
Ensino Superior
Certidão de incapacidade
multiusos
Informação da situação
perante o emprego
DGES
DGCI/DGITA
Min. Educação
Min. Saúde
IISS
Descrição
Indica se determinado contribuinte possui ou não
dívidas ao fisco
Indica se determinado contribuinte possui ou não
actividade aberta
Indica se determinado aluno se encontra matriculado
no ano lectivo.
Indica se determinado aluno se encontra matriculado
no ensino superior no ano lectivo.
Prova periódica da situação para cidadãos portadores
de incapacidade
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.
Página 11 de 35
iAP
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)
AES 256 bits
SHA1
DH 5
Tempo de vida: 86400 segundos
SA de IKE (alternativa)
3DES
SHA1
DH 2
SA de IPSec (preferencial)
ESP (AES 256bits, MD5)
SA de IPSec (alternativa)
ESP (3DES, MD5)
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;
Página 12 de 35
iAP
o
Utilização opcional de autenticação http basic auth;
o
WS-Addressing
v1.0
(http://www.w3.org/TR/ws-addr-core/),
como
correlacionamento de mensagens em modelo de comunicação assíncrona;
forma
de
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.
Página 13 de 35
iAP
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;
Página 14 de 35
iAP
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
Página 15 de 35
iAP
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:
Página 16 de 35
iAP

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.
Entidade – Portal
institucional
Internet
Autenticação
com Cartão de
Cidadão
Portal Web da Entidade
Sistemas de Suporte à Identificação
do Cidadão
Fornecedor de Autenticação
a
Serviços de validação do
Cartão de Cidadão
Fornecedor de
Autenticação
Fornecedor de
dados qualificados A
b
1
4
2
3
Plataforma de
Interoperabilidade
Circuito de autenticação
(sobre norma SAML)
Smart Card Reader
Interacção entre sistemas
via web browser
Interacção com utilizador
Cidadão Nacional
(c/Cartão da Cidadão)
Página 17 de 35
Fornecedor de
dados qualificados B
iAP
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
Página 18 de 35
iAP
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
Página 19 de 35
iAP
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)
Página 20 de 35
iAP
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:
Portal do Cidadão
1
Internet
Autenticação
com Cartão de
Cidadão
Fornecedor de
Autenticação
7
2
4
6
3
8
Site Entidade
Smart Card Reader
via web browser
5
Cidadão
Site Entidade
(sobre norma SAML)
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;
Página 21 de 35
iAP

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.
Pedido de Autenticação
Fornecedor de
Autenticação (FA)
Portal Web do Organismo
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.
Página 22 de 35
iAP
Entidade – Portal
institucional
Internet
Autenticação
com Cartão de
Cidadão
Fornecedor de
Autenticação
1
2
4
Smart Card Reader
3
(sobre norma SAML)
via web browser
Cidadão Nacional
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);
Página 23 de 35
iAP
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);
Página 24 de 35
iAP
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
1.
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;
Página 25 de 35
iAP
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);
9.
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
Página 26 de 35
iAP
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:

4.4.2.
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.
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.
Página 27 de 35
iAP
É 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
1.
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);
7.
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.
Página 28 de 35
iAP
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:
Página 29 de 35
iAP
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:
Rt  Ct , 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.
Página 30 de 35
iAP
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 PPAP 1:
Custo de configuração por
método de pagamento
Custo por pagamento (**)
638 € (*)
até 12.000 pagamentos
0,120 €
Mais que 600.000 pagamentos
0,020 €
0,100 €
0,080 €
0,060 €
0,035 €
(*) – 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:
1

Custos de manutenção evolutiva da Plataforma;

Correcções de anomalias;

Custos de comunicações;

Custos de licenciamento;
Aos custos apresentados acresce IVA à taxa legal em vigor
Página 31 de 35
iAP

Etc.
O custo de manutenção dispendido pelos organismos aderentes à Gateway de SMS resulta da aplicação das
seguintes condições2:
2
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:
Aos custos apresentados acresce IVA à taxa legal em vigor
Página 32 de 35
iAP
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 eGOV, 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;
Página 33 de 35
iAP
6.1.
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.
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.
Página 34 de 35
iAP
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
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
WS-Security
Segurança de integridade e
confidencialidade da
comunicação Web
http://www.w3.org/TR/soap12-part1/
http://www.oasisopen.org/committees/tc_home.php?wg_abbrev=ws
rm
http://www.oasisopen.org/committees/tc_home.php?wg_abbrev=ws
s
http://docs.oasis-open.org/ws-sx/wssecuritypolicy/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.oasisopen.org/committees/tc_home.php?wg_abbrev=sec
urity
Página 35 de 35

interoperabilidade na administração pública

Transcrição

Documentos relacionados

abaction

1ª aula - História da Saúde Pública - SUS

Cópia de Biometria 2 - Sumário

MANUAL DE ACESSO À INTERNET ATRAVÉS DA

MANUAL DE ACESSO À INTERNET 1º Passo

Configurações Básicas para ativar e configurar o WebProtection

ENIAC ABRE WI-FI PARA ALUNOS, FUNCIONÁRIOS E VISITANTES

Baixar - Soft. Livre na Campus Party

Passo a passo para autenticação de Livro Digital - SPED

1. acessar a pasta do programa 2. entrar nas pastas

Serviços terceirizados de qualificação da cadeia de fornecedores