Identidade federada e os sistemas de saúde

Publicado em: 20 de novembro de 2008

Por Mario Szpuszta

Resumo:

O mercado de assistência médica é dos que mais crescem no setor de TI. Também é um dos setores mais delicados e desafiadores. Isso se deve ao ambiente técnico altamente heterogêneo e aos vários interesses políticos das partes envolvidas, de médicos e farmácias a hospitais e o ministério da saúde. Para os arquitetos, esses ambientes significam construir mecanismos de conexão: os nossos sistemas precisam estar aptos a lidar com a diversidade técnica e os interesses políticos, especialmente quando se fala de responsabilidades e segurança. Os conceitos da visão do metasistema de identidade e a sua abordagem federada nos ajuda a compor e construir esses sistemas.

Neste artigo, discutiremos estes conceitos básicos e detalharemos as propostas que fizemos durante o acordo para a construção de um protótipo com a Austrian Medical Association, SVC GmBH, subsidiária de TI da seguradora nacional austríaca responsável pela infra-estrutura eletrônica do cartão de identidade de assistência médica da Áustria e com o Microsoft Innovation Center de Copenhague.

Nesta página

Federação e a visão do metasistema de identidade
Infra-estrutura do sistema de saúde austríaco e planos futuros
Proteger os dados do paciente é o mais importante
Um primeiro passo: o sistema e-card como um serviço de token de segurança
A próxima etapa: modelo de segurança federada
Podemos implementar o modelo? Mapeando tecnologias!
Conclusão
Sobre o autor

Federação e a visão do metasistema de identidade

Resumindo os conceitos e o objetivo principal da visão do metasistema de identidade, originalmente inventada por Kim Cameron, em uma frase: é um desafio, como se pode ver pela leitura do artigo do Kim no MSDN (https://msdn.microsoft.com/en- us/library/ms996456.aspx; uma lista condensada das sete leis de identidade aparece no artigo do Fernando Gebara Filho, na página 4). Um dos primeiros alvos da visão do metasistema de identidade é o desenvolvimento de conceitos, modelos e processos para unificar e estruturar o modo com que lidaremos com as identidades digitais no futuro, de todas as perspectivas, inclusive as partes que emitem identidades digitais, confiam nelas e, especialmente importante, negociam com identidades digitais (nós, como usuários finais).

Hoje, esses conceitos, modelos e processos não existem, de fato, como uma camada comum padronizada que abrange todas as áreas. Esse é o motivo principal pelo qual nós, usuários finais, estamos perdendo o controle de nossas informações, impressões digitais, na nuvem.

Estamos compartilhado informações sobre nós mesmos de forna não estruturada com várias e diferentes partes. (Quantos perfis de usuário você tem?) Especificamos informações para todos os registros com um site na Internet e, por fim, perdemos controle sobre o que dissemos, onde e porquê. Ainda mais interessante é a realidade de estarmos protegendo essas informações com mecanismos muito fracos, como combinações de nome de usuário e senha, que podem ser facilmente roubadas (vide www.antiphishing.org).

Ao definir padrões que incluem conceitos, modelos e processos comuns, com funções claras para o tratamento das identidades digitais, a visão do metasistema de identidade tenta resolver as questões acima mencionadas. Esses conceitos têm como alvo a "camada de identidade padronizada" faltante em modelos de camadas típicos, como a interconexão de sistemas abertos (Open System Interconnection, OSI). Hoje, eles incluem padrões para questões como resolução de comunicação ou endereço; mas, não falam sobre identidades. A Figura 1 ilustra um modelo que evoluiu no metasistema de identidade. Este modelo enfatiza a clara separação das responsabilidades das várias partes, assim como os caminhos de comunicação entre elas.

O modelo estabelece a diferença entre provedores de identidade, partes confiantes e sujeitos. Um provedor de identidade (identity provider, IP) é essencialmente responsável pelo gerenciamento das nossas informações. Em geral, confiamos nos provedores de identidade e, assim, permitimos que armazenem as nossas informações pessoais. Os provedores de identidade também validam identidades e confirmam a veracidade das informações de um indivíduo. Tecnicamente, um provedor de identidade é um Web Service denominado "serviço de token de segurança" (Security Token Service, STS), que implementa determinadas interfaces. Depois, temos as partes confiantes (relying parties, RP), implementadas como aplicativos ou serviços. Em geral, as partes confiantes têm algumas ofertas que disponibilizam aos sujeitos, desde que estes possam comprovar determinadas exigências. Essas exigências são instruções sobre nós, denominadas "declarações". Essas instruções associam usuários finais a propriedades, permissões ou algo assim. Por isso, a parte confiante acredita no provedor de identidade que pode confirmar a veracidade dessas instruções. A autorização da parte confiante se baseia nas instruções confirmadas por um provedor de identidade. Em geral, este mecanismo é chamado de segurança baseada em declarações. Por fim, há o sujeito, que representa os indivíduos no modelo. Todos os indivíduos precisam confirmar as instruções sobre si mesmos ao acessarem os serviços de uma parte confiante. Se essa parte confiante solicitar uma confirmação, o sujeito sabe qual provedor de identidade deve usar para fornecer a necessária lista de instruções confirmadas. Ao fazer essa seleção, o sujeito também decide quais informações são encaminhadas à parte confiante. Em essência, o sujeito seleciona uma identidade em um dispositivo denominado seletor de identidades. Esse dispositivo e os seus padrões subjacentes fornecem a "experiência de usuário comum e unificada". Os seletores de identidade não se incluem no escopo deste artigo. Confiamos essencialmente na separação de funções e também nos protocolos definidos no modelo apresentado na Figura 1.

É preciso ter em mente um fato importante sobre este modelo: ele não define nenhum tipo específico de autenticação contra o provedor de identidade e tampouco estabelece qualquer token de segurança específico a ser emitido pelos provedores de identidade. Ele apenas especifica uma separação clara de responsabilidades e define caminhos de comunicação com base nos protocolos de Web Service padronizados os quais, por sua vez, se baseiam no aproveitamento de padrões WS-*, como poderão ver na última seção deste artigo. Outro fato importante é que as partes confiantes não são mais responsáveis pelas informações de armazenamento e gerenciamento sobre os sujeitos. Essa tarefa é dos provedores de identidade prevendo que a longo prazo, nós, como usuários, tenhamos apenas alguns provedores de identidade confiáveis que armazenam as nossas informações - como acontece no mundo real. Esta é uma grande diferença do mundo digital de hoje, em que quase todo site da web cria perfis de usuário e armazena todos os dados pessoais informados para esses perfis também em outros sites. No mundo real isso é muito diferente. Apenas alguns provedores de identidade têm informações sobre nós e, em geral, sabemos quais informações eles têm. Além do mais, no mundo real a maioria dos provedores de identidade não armazena as mesmas informações sobre nós repetidamente. Quando precisam dessas informações, dependem de outros provedores de identidade. Isso tem alguns efeitos interessantes: nenhuma central de armazenamento de dados pode guardar todas as nossas informações (isso é importante pela perspectiva da privacidade e da proteção de dados) e as responsabilidades sobre a confirmação de instruções dos sujeitos pode ser delegada a um conjunto de provedores de identidade. E isso me traz ao aspecto mais importante do modelo da Figura 1 para a nossa discussão sobre sistemas de saúde: a flexibilidade deste modelo por suas características e pelo fato de que a "autenticação" contra o provedor de identidade não está definida de nenhum forma, nos permite fazer o que fazemos no mundo real: construir cadeias de confiança e delegar responsabilidades entre os provedores de identidade. O que isto significa? Bem, a autenticação contra provedores de identidade pode acontecer por meio de mecanismos de autenticação clássicos como smartcards, Kerberos (vinculado a nome de usuário, senha; sim, isto é possível), certificados ou (e esta é a parte interessante) por meio de um token emitido por outro provedor de identidade. Cada provedor de identidade também pode ser uma parte confiante de outro provedor de identidade. Isso nos ajuda a construir sistemas federados com cadeias de confiança e delegação de responsabilidade as quais, por sua vez, ajudam a fazer a conexão entre silos políticos e técnicos. A Figura 2 ilustra este conceito.

Como se nota, o provedor de identidade 1 exige um token emitido pelo provedor de identidade 2 que comprove determinadas informações, antes de o provedor de identidade 1 poder provar outras informações exigidas pela parte confiante. Neste cenário, cada provedor de identidade pode provar um determinado grupo de instruções sobre um sujeito e, assim, ter condições de fazer a associação de permissões com o sujeito; todavia, nenhum dos IPs pode provar todas as informações necessárias sobre o sujeito. Em seguida, a parte confiante autoriza com base nas declarações comprovadas por um ou pelos dois provedores de identidade. Essencialmente, os provedores de identidade controlam as autorizações da parte confiante fornecendo (ou não fornecendo) determinadas declarações. Assim, na Figura 2, temos dois provedores de identidade que podem afetar as decisões de autorização feitas pela parte confiante, independentemente ou juntos. Com isso, agora podemos discutir como esses conceitos podem ser usados para estruturar de modo efetivo a segurança em um ambiente federado, com base nas propostas que fizemos na Áustria.

Infra-estrutura do sistema de saúde austríaco e planos futuros

A Áustria tem instalada uma infra-estrutura disponível para todos os cidadãos segurados e para a maioria dos médicos denominada sistema e-card. Originalmente, o sistema e-card foi projetado para suportar o processamento eletrônico de tarefas relativas ao seguro como pagamentos para tratamentos sem a necessidade de outros documentos. Para pacientes, isso significa estar despreocupado com certificados de seguro-saúde impressos em papel. O sistema e-card envolve smartcards para pacientes e médicos, alguns equipamentos especiais que os médicos precisam instalar em seus consultórios para uso do sistema e-card e serviços de back-end para consultar informações sobre os portadores de e-card e dar início aos processos de back-end baseados no seguro. Para os fins deste artigo, não precisamos abordar os detalhes técnicos sobre o sistema de e-card e a sua implantação.

Embora o sistema e-card seja visto como uma plataforma para capacitar muitos serviços de "e-saúde" futuros, na verdade é apenas um sistema no cenário complexo e heterogêneo de outros sistemas na Áustria. Em primeiro lugar, a disponibilidade dos e-cards é limitada a pacientes cobertos pelo seguro nacional. Não inclui pessoas sem esse seguro, quer estejam apenas visitando a Áustria ou não. Esses pacientes precisam ter outros meios de autenticação, como carteiras de identidade do país. Em segundo lugar (e mais importante) está a questão da responsabilidade e do controle político. O seguro nacional deseja gerenciar algumas, mas não todas as informações sobre pacientes e médicos. Por exemplo, não guardam as fichas médicas completas como exames de laboratório ou relatórios de análises dos hospitais porque "isso não faz parte do seu trabalho". A responsabilidade de gerenciar esses tipos de informações é atribuída aos hospitais ou a médicos de outras especialidades (como os médicos de laboratórios). Isso significa que eles também são responsáveis pela guarda das informações dos pacientes. Para aceitar pacientes com e sem e-cards, eles precisam aceitar vários tipos de autenticação. Isso traz à tona uma situação em que as informações do paciente (registros) estão espalhadas pelo país, entre várias e diferentes partes.

A vantagem disso é que não há um ponto único de ataque para aqueles que desejam macular a privacidade e a segurança do paciente.

Por outro lado, não seria ótimo se um médico ou hospital tivesse acesso a todas as informações pertinentes sobre um paciente para assegurar o melhor tratamento médico possível? Lógico que seria, e é por isso que o ministério da saúde austríaco formou um grupo de trabalho para projetar um sistema para o gerenciamento eletrônico de fichas médicas. Esse sistema daria a médicos, hospitais, farmácias e pacientes o acesso a todas as informações médicas necessárias. O acesso estaria disponível em qualquer lugar do país, sempre que necessário, mas apenas com a anuência do paciente. Uma solução centralizada não é uma opção para a Áustria em decorrência da lei de proteção de dados instituída no país, muito rígida, que protege a segurança e a privacidade do paciente de várias formas.

Assim, armazenar as informações de modo distribuído através de vários sistemas gerenciados em várias partes é uma exigência principal para um sistema eletrônico de fichas médicas. E esta é uma das principais razões de termos adotado uma abordagem federada ao projetar o nosso protótipo. Além disso, a arquitetura precisa suportar outros tipos de autenticação, além do e-card. O sistema e-card é um padrão largamente implantado e aceito e desempenhará uma função importante nos futuros desenvolvimentos de e-saúde da Áustria. Portanto, usamos o e-card como um ponto de partida e trabalhamos com propostas para ampliar as suas interfaces de serviço para suportar cenários de identidade federada.

Proteger os dados do paciente é o mais importante

Um dos maiores debates em todas as discussões sobre fichas médicas eletrônicas ocorre ao redor da segurança e privacidade do paciente. A Áustria tem uma das leis de proteção de dados mais rígidas do mundo e é um exemplo em toda a União Européia. Rápido e simples: a lei de proteção de dados estipula que o acesso a QUALQUER informação sobre um indivíduo deve ser aprovada por esse indivíduo TODAS as vezes. De acordo com a Associação Médica Austríaca, deve-se adotar a combinação de processos organizacional e técnico para permitir o seguinte (e o provedor de serviços de saúde pode ser qualquer parte com ofertas de assistência médica como médicos, farmácias, hospitais, etc.):

• 1. Os pacientes devem ter a oportunidade, a cada consulta com um provedor de serviços de saúde (ou seja, médico) de anuir explicitamente sobre o acesso aos seus dados pessoais (ficha médica). Se os pacientes não consentirem, os seus dados não poderão ser acessados.

• As informações sobre um paciente em sistemas de e-saúde só podem estar disponíveis a outros provedores de assistência médica para outros tratamentos com o consentimento explícito e adicional (além do consentimento geral descrito no item 1 acima) concedido em conversa confidencial com o provedor de serviços de saúde (médico).

Embora alguns detalhes organizacionais ainda estejam sendo discutidos entre os vários partidos políticos, todos concordam com a adoção de um processo como o descrito nesta seção. Esta exigência influenciou definitivamente a forma com que projetamos o nosso protótipo.

Um primeiro passo: o sistema e-card como um serviço de token de segurança

Com base nos conceitos da visão do metasistema de identidade, nas versáteis decisões de autorização e na necessidade de uma arquitetura de segurança federada para os sistemas de e-saúde na Áustria, tivemos a idéia de ampliar o sistema e-card para um serviço de token de segurança. Assim, o sistema e-card emite os bilhetes com base no processo de autenticação de e-cards bem estabelecido. Os bilhetes trazem declarações, ou seja, instruções essenciais sobre o paciente e/ou médico em uma situação específica. Esses bilhetes, ou as declarações dos bilhetes, permitem aos sistemas de e-saúde (como um sistema de prescrição eletrônico) tomar as decisões de autorização. Os bilhetes precisam ser assinados de modo digital pelo sistema de ecard para que os sistemas de e-saúde confiantes possam acreditar nos bilhetes e aceitá-los como confirmação das informações específicas sobre pacientes, médicos e a situação atual na qual estão agindo. A Figura 3 ilustra este simples mas poderoso conceito.

Nesta solução, o bom é que estamos dividindo as responsabilidades, da mesma forma como propõe a visão do metasistema de identidade com os seus modelos. O sistema de e-saúde já não é mais responsável por autenticar a solicitação. Ele delega esta tarefa complexa a um serviço originalmente construído para autenticar pacientes e médicos: o sistema e-card. Significa que todos os serviços de e-saúde precisam apenas dizer aos seus clientes quais instruções sobre o paciente, médico e a situação atual precisam ser confirmadas e qual provedor de identidade tem condições de confirmar essas instruções. Em nosso protótipo, o provedor de identidade é o sistema e-card que em seguida realiza esta tarefa complexa, caso a autenticação do e-card tenha sido bem-sucedida. Mas a arquitetura também dá ao sistema de e-saúde a capacidade de aceitar bilhetes de outros provedores de identidade para suportar outros tipos de autenticação como as carteiras de identidade (por exemplo, de outros países).

Oferece também ao serviço de e-saúde a capacidade de aceitar bilhetes de provedores de identidade, os quais confirmam informações adicionais sobre um paciente, comparando-o àquele confirmado pelo sistema e-card. Neste cenário, teríamos uma cadeia de confiança entre outro provedor de identidade e o sistema e-card como um provedor de identidade. Além do mais, a autorização no âmbito do próprio serviço de e-saúde é bastante simples: ele apenas consulta e analisa as declarações armazenadas no bilhete criado e assinado pelo sistema e-card e encaminhado por meio do software executado no consultório do médico.

Agora, vamos analisar as exigências de proteção de dados como um exemplo de como as declarações podem simplificar a implementação das partes confiantes. Consultando a seção anterior sobre proteção de dados, ela poderia ser implementada com a arquitetura baseada em declarações e o sistema de ecard como um serviço de token de segurança, como segue (cenário simplificado):

• O paciente consulta um médico e usa o e-card para autenticação passando o e-card no leitor de cartões. Durante o processo de autenticação, o paciente tem a oportunidade de concordar, formalmente, em permitir o acesso do médico à sua ficha médica eletrônica.

• O sistema e-card emite um bilhete diferente, de acordo com a anuência ou recusa do paciente. Se o paciente concordar, o bilhete poderá conter uma declaração assinada pelo sistema de e-card que estipula que o médico (o seu software) terá acesso de leitura (apenas) à ficha médica eletrônica do paciente pelo período de validade do bilhete. Na sua forma mais simples, esta declaração poderia ser um indicador booleano. Como está assinado pelo sistema e-card e emitido durante o processo de autenticação, outros serviços de e-saúde podem confiar nessa declaração do bilhete assinado e conceder acesso às partes específicas dos respectivos serviços e informações.

• A seguir, o paciente faz a consulta privada com o médico. Durante essa discussão, o software do médico pode usar o bilhete emitido anteriormente. Ao final da discussão, o médico cria um relatório do diagnóstico que poderia ser útil para outros médicos durante o tratamento do paciente. De acordo com as nossas exigências de proteção de dados descritas na seção anterior, o paciente precisa ter a oportunidade de dar o seu de acordo para esta etapa, explícito e adicional, passando o seu e-card uma segunda vez no leitor de cartões e executando outro processo de autenticação. Durante o processo de autenticação, o sistema e-card exige a sua inserção e também do bilhete anteriormente inserido para emissão de outro, que inclui uma declaração para verificar se o paciente estabeleceu uma exigência adicional.

• Este novo bilhete é usado pelo software do médico para acessar um serviço de e-saúde que permita compartilhar relatórios de diagnóstico com outros médicos. Este serviço de e-saúde fará a divulgação de relatórios apenas se obtiver um bilhete com a declaração que confirma se o paciente fez a segunda autenticação. Os mecanismos para implementar esse serviço são exatamente iguais aos outros: o serviço só avalia uma declaração adicional em um bilhete emitido pelo sistema e-card. O serviço e-saúde pode confiar nesse bilhete e na declaração porque ele foi emitido pelo sistema e-card de confiança; por sua vez, este sistema só emite o bilhete com base em outro, anteriormente emitido informando o primeiro login.

Com a adoção desse processo e arquitetura, a nossa proposta arquitetural possibilitaria uma implementação bastante simples em duas etapas e nos termos da lei de proteção de dados. E, além disso, esta exigência complexa e crítica seria depois implementada em um único lugar e não repetidas vezes para cada serviço, pois o sistema e- card pode fazer a verificação paciente-acordo para nós, como um provedor de identidade. Isto demonstra o poder da segurança baseada em declarações e como simplifica a forma com que lidamos com exigências especialmente mais complexas. O meu primeiro pensamento foi: "Não é possível que seja assim simples". Mas, quando se pensa em como as coisas funcionam no mundo real, temos de admitir que o mundo real é quase tão simples. Freqüentemente, as decisões de autorização são tomadas com base nas instruções simples de um cartão de identificação ou em um crachá de conferência (por exemplo, as pessoas que portam crachás com uma faixa vermelha são palestrantes e podem entrar na sala de espera a eles destinada, os outros não).

Estender o sistema de e-card para um serviço de token de segurança foi apenas o primeiro passo. No final, o sistema e-card pode provar uma grande quantidade de informações sobre pacientes, médicos, etc., mas não todas as informações que possam ser necessárias para qualquer serviço de e-saúde futuro. Além disso, o sistema e-card e seus proprietários não desejam deter todas as informações por motivos políticos, e isso nos levou à próxima idéia de estender o modelo a um sistema de segurança federado com base nos padrões propostos pelo metasistema de identidade.

"O PODER DA SEGURANÇA BASEADA EM DECLARAÇÕES ESTÁ EM SIMPLIFICAR A FORMA COM QUE LIDAMOS COM EXIGÊNCIAS ESPECIALMENTE MAIS COMPLEXAS".

A próxima etapa: modelo de segurança federada

O raciocínio que apoiou a criação de um modelo de segurança federado foi que o sistema e-card não terá condições de entregar todas as declarações em bilhetes, o que pode ser necessário para os vários serviços de e-saúde do futuro. Além disso, por motivos políticos, os responsáveis pelo sistema e-card não querem fornecer todos os possíveis tipos de declarações para tomar (!!) decisões de autorização. De acordo com eles, outros têm o know-how e a posição política necessários para gerenciar declarações que exijam decisões de autorização mais específicas. Portanto, a idéia foi a seguinte: se um sistema de e-saúde exigir informações (declarações) adicionais para executar uma autorização, e se essas informações não puderem ser disponibilizadas pelo sistema de e-card, deveria ser possível introduzir serviços de token de segurança adicionais capazes de emitir bilhetes para acesso a esses serviços de e-saúde específicos (ou um conjunto específico de serviços de e-saúde). Por certo, esses sistemas devem ter uma relação de confiança com o sistema e-card e emitirão bilhetes com base em um bilhete já emitido pelo sistema e-card, caso confiem na autenticação do e-card.

Vamos assumir um cenário típico, possível: um sistema de emissão de relatórios de diagnóstico que, para poder limitar o acesso a esses relatórios, precisa tomar decisões de autorização baseadas em detalhes definidos pelos laboratórios, especialistas do laboratório, hospitais e médicos. Esses detalhes são, provavelmente, desconhecidos pelo sistema e-card e, portanto, as declarações necessárias para possibilitar uma autorização são gerenciadas pelas partes já mencionadas (laboratórios, médicos, etc.). Para a emissão dessas declarações, é necessário ter um serviço de token de segurança adicional. A Figura 4 ilustra este cenário com um serviço de e-saúde que exige ter o próprio serviço de token de segurança.

Esta arquitetura aceita futuras extensões flexíveis da infra-estrutura de segurança no sistema pela adição de novos serviços de token de segurança na medida em que surgirem novas características de autorização que exijam outros tipos de declarações, sem perder nem afetar os investimentos existentes. O modelo também permite dividir as "responsabilidades de autorização" por vários motivos: políticos, técnicos e até de knowhow. Por fim, o modelo também permite a consolidação dos serviços de token de segurança caso o cenário se modifique, e a simplificação é possível por qualquer razão, sem realmente afetar a implementação dos vários serviços de e-saúde. Para os serviços de e-saúde, apenas o provedor de identidade muda, com algumas extensões ou consolidações no âmbito do sistema como um todo. Se os tipos de declarações permanecem disponíveis, só será preciso configurar outro STS para o serviço de e-saúde e todo o restante se mantém perfeito. A Figura 5 ilustra esta situação.

Como você pode ver na iteração 3 da Figura 5, é possível incluir outros mecanismos e fatores de autenticação mais adiante e ainda reutilizar os serviços de e-saúde existentes afetar as respectivas implementações, desde que os tipos de declarações permaneçam os mesmos. Estas são exatamente a flexibilidade e agilidade que necessitamos para ambientes complexos e heterogêneos, como é o setor de assistência médica. . É por isso, também, que esforços de padronização, como os do IHE (Integrating the Heathcare Enterprise), estão sendo envidados nesta direção (ainda que o IHE deixe abertos os padrões e protocolos usados e permaneça em um nível ainda mais conceitual).

Podemos implementar o modelo? Mapeando tecnologias!

Um modelo arquitetural não vale nada se não pudermos implementá- lo. Portanto, na próxima etapa precisaremos avaliar em que ponto estão as tecnologias e se é prático implementar um sistema como descrito anteriormente. Em primeiro lugar, precisamos definir os padrões para implementação do modelo de segurança federada como proposto na visão do metasistema de identidade. A Figura 6 destaca os padrões mais importantes.

Todos esses padrões fazem parte da pilha WS-*, padronizada pela OASIS sobre os padrões W3C existentes para Web Services. Entretanto, ter padrões não significa, necessariamente, que possamos implementar os sistemas facilmente. Então, o que dizer do suporte no desenvolvimento de frameworks e runtimes? Em termos gerais, o mundo do metasistema de identidade é muito mais real e a melhor prova disso é a conferência Catalyst Europe realizada em outubro de 2007 (consulte http://www.identityblog.com/?p=889). Nessa conferência, vários fornecedores de tecnologia (comerciais e de código aberto) foram convidados a testar a interoperabilidade das respectivas parte confiante, provedor de identidade e seletor de identidade/implementações de sujeito e os resultados foram bastante promissores. A interoperabilidade baseada nos padrões apresentados na Figura 6 trabalha entre várias plataformas incluindo Microsoft .NET, Java, PHP e até mesmo Ruby. Na conferência Catalyst Europe, os fornecedores puderam confirmar a interoperabilidade entre as várias plataformas como Eclipse Higgins, xmldap.org, Bandit (Novell), Verisign PIP e a Microsoft .NET Framework. A plataforma .NET Framework suportou os protocolos necessários desde a versão 3.0 com o Windows Communication Foundation (WCF). Os seletores de identidade digital são suportados pelo Windows CardSpace, também parte da plataforma .NET Framework 3.0. O vínculo do protocolo a ser usado do WCF é o wsFederationHttpBinding (para mais informações, leia o seguinte artigo no MSDN: https://msdn.microsoft.com/en-us/library/ aa395215.aspx).

Conclusão

A assistência médica como um ambiente heterogêneo, política e tecnicamente complexo, é definitivamente um dos lugares em que os conceitos e as idéias da visão do metasistema de identidade sentem-se em casa. Discutimos os conceitos mais importantes do metasistema de identidade que ajudam a construir os serviços nesse ambiente complexo. Esses conceitos incluem uma separação clara de funções e responsabilidades.

Estes estão divididos em provedores de identidade, partes confiantes e sujeitos. O metasistema também define os caminhos e protocolos de comunicação baseados nos padrões de Web Services WS-*. Esses conceitos podem ser aplicados observando-se o protótipo que construímos na Áustria em conjunto com a Austrian Medical Association, o SVC GmbH. (subsidiária de TI da seguradora nacional) e o Microsoft Innovation Center em Copenhague. Funções e responsabilidades claramente definidas ajudam os arquitetos a construir sistemas de baixo acoplamento nos quais partes diferentes com interesses diferentes estão envolvidos pelo desacoplamento das permissões de autenticação e atribuição por meio de declarações do código de autorização real nos serviços do negócio, sempre baseados em padrões WS-* abertos. Estes são os tipos de arquitetura que nos ajudam a construir mecanismos de conexão, quer sejam técnicos ou políticos!

Sobre o autor

Mario Szpuszta trabalha como arquiteto no Developer and Platform Group da Microsoft na Áustria e coordena arquitetos de software de contas corporativas e as principais dez contas de web sites nesse país. Ele sempre se dedicou ao trabalho com as tecnologias da Microsoft e começou trabalhando com o .NET Framework, bem no início. Nos últimos anos, concentrou-se no desenvolvimento de software seguro, desenvolvimentos ASP.NET para web, Web Services e também na integração de clientes e servidores do Microsoft Office em aplicativos personalizados utilizando os produtos Microsoft .NET, Office Open XML File Formats e Web Services. Mario é co-autor do livro “Advanced .NET Remoting 2a. Edição” com Ingo Rammer e participou na elaboração dos trabalhos “Pro ASP.NET 2.0 in C#” e do “Pro ASP.NT 3.5 in C#” com Matthew MacDonald.