OpenID para aplicativos Java Web, Parte 2: Escrever um OpenID Provider para autenticação única

Saiba como usar OpenID para proteger recursos de aplicativos Java™ Web de usuários não autenticados. Nesta segunda parte de sua introdução à especificação da OpenID Authentication, Steve Perry mostra como usar a biblioteca openid4java para criar um OpenID Provider em um cenário de aplicativo com logon único. Se estabelecer um aplicativo como um OpenID Provider em uma arquitetura de "loop fechado", é possível permitir que usuários finais façam logon apenas uma vez para acessar vários aplicativos. Você também saberá como usar a extensão OpenID Attribute Exchange (AX) para a troca de dados personalizados entre provedores e parceiros dependentes do OpenID.

J Steven Perry, Principal Consultant, Makoto Consulting Group, Inc.

Photo of J Steven PerryJ. Steven Perry é um consultor de desenvolvimento de software independente e vem desenvolvendo software profissionalmente desde 1991. Steve tem paixão por desenvolvimento de software e gosta de escrever sobre desenvolvimento de software e de orientar outros desenvolvedores. Ele é autor de Java Management Extensions (O'Reilly) e Log4j (O'Reilly), e Joda-Time (que escreveu para o IBM developerWorks). Em seu tempo livre, ele sai com seus três filhos, anda de bicicleta e ensina ioga. Steve é o proprietário e o principal consultor do Makoto Consulting Group, localizado em Little Rock, Arkansas.



06/Abr/2010

OpenID ganha cada vez mais espaço como solução confiável de autenticação e gerenciamento de identidade que permite aos usuários finais acessarem sites na Web e outros recursos online usando um ID do usuário reconhecido universalmente. Na Parte 1, apresentei a especificação da OpenID Authentication e mostrei como incorporá-la a um aplicativo Java Web usando a implementação da biblioteca openid4java.

Na maior parte desse artigo, focamos no OpenID Relying Party (RP), que é um recurso on-line como um Web site ou MP3 que usa o OpenID para registro e autenticação. A outra parte da especificação OpenID Authentication é o OpenID Provider (OP). O OP ajuda usuários a reivindicar um OpenID e autentica usuários que tentam fazer login nos recursos da Web compatíveis com o OpenID.

Já existem muitos OpenID Providers (entre os quais, myOpenID, que foi o OP do sistema de registro do aplicativo Java Web que analisamos na Parte 1), e na maioria dos casos não há necessidade de repetir tudo.

Um cenário no qual faria sentido construir o seu próprio OP é o cluster de aplicativos em que vários aplicativos compartilham recursos em uma rede confiável. Nesse caso, talvez você queira criar um sistema seguro, em "loop fechado". Seria conveniente deixar que o usuário faça logon de uma vez em todos os aplicativos, em vez de ter que fazer logon em cada aplicativo isoladamente. Fazer com que um aplicativo no cluster aja como o OP permitiria a configuração da autenticação única para todos os aplicativos.

Neste artigo, focaremos em escrever um OpenID Provider para proteger vários aplicativos em uma arquitetura de loop fechado. Começaremos com uma análise mais detalhada dos benefícios e da estrutura da autenticação única e, depois, veremos a codificação de um OpenID Provider simples em uma arquitetura de cluster. Mais uma vez, usaremos a biblioteca openid4java para fornecer os principais recursos de tempo de execução para o sistema de autenticação e assegurar que o nosso OpenID Provider esteja em conformidade com a especificação OpenID Authentication.

Autenticação única

Em alguns cenários empresariais faz mais sentido combinar aplicativos que tenham funcionalidade e competências principais distintas do que tentar embutir toda a funcionalidade em um único aplicativo. Esses clusters de aplicativos quase sempre ocupam o centro do B2B, em que cada parceiro apresenta alguma coisa no momento da negociação que aumenta o valor de uma proposta de negócio como um todo.

O desafio de desenvolver um desses clusters é a autenticação. Não funciona fazer com que cada aplicativo autentique o usuário final isoladamente, pelo menos não da perspectiva do usuário final.

Em um sistema de clusters que usa o padrão OpenID para autenticação, cada aplicativo do parceiro delega autenticação ao OP. Cada aplicativo garante que o acesso à sua funcionalidade e recursos é seguro, e os usuários finais têm a conveniência de fazer logon apenas uma vez por sessão.

Vamos observar atentamente os componentes que participam de um sistema de autenticação única. Observe que a arquitetura discutida abaixo se fundamenta no exemplo de aplicativo desenvolvido na Parte 1.

Open ID Relying Party (RP)

Um OpenID Relying Party, como você deve se lembrar, é um Web site ou outro recurso on-line que exige acesso seguro aos seus conteúdos. Um RP usa um OpenID Provider (OP) para autenticar usuários. O RP também pode usar as extensões Simple Registration (SReg) ou Attribute Exchange (AX) (ver Recursos) para solicitar registro ou identificar informações sobre usuários. O RP faz solicitações SReg e AX quando ele pede ao OP para autenticar o usuário por meio de chamadas à biblioteca openid4java.

Mais informações sobre SReg

O exemplo de aplicativo da Parte 1 usava a extensão OpenID Simple Registration para permitir que o RP solicitasse informações do usuário ao OP. Consulte "OpenID para aplicativos Java Web, Parte 1" para obter mais informações sobre a extensão SReg do OpenID. O aplicativo deste artigo usará a extensão OpenID Attribute Exchange, que permite transações de informações mais complexas.

Open ID Provider (OP)

O OpenID Provider fornece autenticação a todos os aplicativos parceiros. Depois que o usuário for autenticado com êxito por meio de chamadas à biblioteca openid4java, o OP cumpre as solicitações SReg e AX do RP. O OP ocupa o centro da arquitetura de logon único que analisaremos neste artigo.

Escrevendo um OpenID Provider

No artigo anterior, vimos como usar a openid4java para escrever um Relying Party para um sistema de registro de aplicativo Java Web. Neste artigo, seguiremos um procedimento similar para o OpenID Provider. A openid4java torna muito simples seguir a especificação OpenID Authentication porque toda a infraestrutura do OpenID já está codificada.

Sobre o exemplo de aplicativo

O objetivo do exemplo do aplicativo é mostrar como o OpenID RP e OP trabalham juntos para proteger um recurso do acesso não autorizado. O exemplo de aplicativo possui um foco muito exato:

  1. O usuário tenta acessar um recurso protegido.
  2. A RP pede ao OP para autenticar o usuário.
  3. O OP autentica o usuário, se ele ainda não estiver conectado.
  4. O RP determina se o usuário conectado tem autorização para acessar o recurso protegido.

O exemplo de aplicativo inclui código para ambos RP e OP para que possamos ver como eles funcionam juntos. Em um cenário real, não implementaríamos os dois componentes no mesmo aplicativo — não faz sentido nenhum! — mas vale a pena vê-los juntos e estudar como interagem.

Listagens de código no mesmo aplicativo

As listagens de código nas seções que seguem mostram as chamadas openid4java API que um OP e RP fazem para usar o OpenID. Uma coisa que você pode perceber é como o exemplo de aplicativo precisa, na verdade, de pouco código para fazer isso acontecer. A openid4java realmente torna sua vida mais fácil. O código que o RP usa é praticamente igual ao código que você viu na Parte 1; por isso, indico que você consulte-a para obter mais informações sobre os detalhes internos do RP. Destacarei algumas diferenças pequenas (principalmente relacionadas ao AX, que não mostrei na Parte 1) à medida que prosseguirmos.

A exemplo do aplicativo que escrevi para o primeiro artigo, este também usa o Wicket como UI. Para reduzir a base do Wicket no exemplo de aplicativo, isolei o código que o OP usa para chamar a openid4java em sua própria classe Java denominada de OpenIdProviderService (em com.makotogroup.sample.model).

OpenIdProviderService.java contém vários métodos que correspondem ao uso da API da openid4java:

  • getServerManager() configura e retorna uma referência à classe openid4java ServerManager.
  • getOpEndpointUrl() retorna a Endpoint URL em que o OP recebe solicitações do RP.
  • processAssociationRequest() usa a openid4java para associar o OP à solicitação do RP.
  • sendDiscoveryResponse() envia uma solicitação de descoberta ao RP.
  • createAuthResponse() cria a mensagem openid4java AuthResponse que é enviada ao RP depois de uma solicitação de autenticação.
  • buildAuthResponse() é o método principal que lida com as solicitações OpenID Simple Registration e Attribute Exchange.

Para iniciar o exemplo de aplicativo, execute Ant [REF] e construa o alvo WAR; depois, copie-o no seu diretório Tomcat webapps e inicie o Tomcat.

Autenticação do OpenID: Passo a passo

Quando o usuário tenta acessar um recurso protegido de um Relying Party (RP), o RP certifica-se de que o usuário é quem ele diz ser (autenticação) e depois decide se lhe concede acesso ou não (autorização). O foco deste artigo é a autenticação; por isso, se o usuário for autenticado pelo OpenID Provider (OP), o exemplo de aplicativo concederá acesso ao recurso protegido. Em um cenário real, o RP também executaria algum tipo de autorização.

Ao executar o exemplo de aplicativo, você verá uma tela com um recurso protegido nela. Ocorrerá a seguinte sequência de eventos, que descreverei com mais detalhes nas próximas seções:

  1. Solicitação para acessar um recurso protegido: O usuário tenta acessar um recurso protegido no Web site do RP.
  2. RP executa a descoberta: O RP envia uma solicitação de descoberta ao OP para estabelecer uma conexão e executar uma associação.
  3. OP responde à solicitação de descoberta: O OP responde corretamente à solicitação de descoberta ao enviar de volta um XRDS (eXtensible Resource Descriptor Sequence) por meio da extensão SReg, Attribute Exchange (AX) ou Política de Autenticação (AP) do OpenID Provider (que não abordarei aqui; consultar Recursos). O XRDS confirma o OP como o provedor de serviço OpenID do usuário.
  4. RP solicita autenticação do usuário: O RP verifica com o OP para ver se o usuário pode ser autenticado. Se o login tiver sucesso, o RP usa as extensões SReg e AX, ou ambas, para solicitar algumas informações sobre o usuário.
  5. OP autentica o usuário: Se o usuário não fez login ou se tiver uma sessão inválida, ele é solicitado a fornecer as credenciais de login. Se a autenticação tiver sucesso, o OP notifica o RP e envia qualquer dado solicitado por meio de SReg ou AX.
  6. RP concede acesso: O usuário recebe acesso ao recurso protegido. Em um cenário real, a maioria dos RPs verifica a autorização do usuário antes de conceder acesso.

A seguir, analisaremos cada etapa detalhadamente.

Por que usar a extensão AX?

Talvez você tenha notado que o exemplo de aplicativo usa ambas as extensões OpenID SReg e AX (consultar Recursos) para passar informações do usuário entre o OP e o RP. Praticamente, as duas extensões permitem que OP e RP comuniquem-se bem. SReg oferece um conjunto limitado de atributos a serem trocados, ao passo que AX pode ser usado para trocar praticamente qualquer informação desde que ambos o RP e o OP o tenham definido como um atributo. Em um cenário de cluster como este, também pode acontecer de cada aplicativo confiável (RP) definir a sua própria "extensão do fornecedor" personalizada. Esse seria outro modo de simplificar a comunicação entre o OP e o RP. Você aprenderá mais sobre a extensão AX ainda neste artigo.

Solicitação para acessar um recurso protegido

O exemplo de aplicativo contém um único recurso protegido. Quando o aplicativo iniciar e você acessar a RP URL, http://localhost:8080/openid-provider-sample-app/, a seguinte página será carregada:

Figura 1. A página principal do exemplo de aplicativo
A página principal do exemplo de aplicativo

Quando o usuário clicar no link, o código na Listagem 1 será executado:

Listagem 1. A página principal do aplicativo que contém o recurso protegido
package com.makotogroup.sample.wicket;
. . .
public class OleMainPage extends WebPage {
  public OleMainPage() {
    add(new OleMainForm("form"));
  }
  public class OleMainForm extends Form {
    public OleMainForm(String id) {
      super(id);
      add(new PageLink("openIdRegistrationPage", new IPageLink() {
        public Page getPage() {
          return new OpenIdRegistrationPage();
        }
        public Class<? extends WebPage> getPageIdentity() {
          return OpenIdRegistrationPage.class;
        }
      }));
    }
  }
}

Observe o código em negrito na Listagem 1. Quando o usuário clicar no link mostrado na Figura 1, o Wicket o leva ao OpenIdRegistrationPage (o recurso). Neste ponto, o destino do link é invocado, que executa o construtor da classe OpenIdRegistrationPage. Esta classe faz duas coisas:

  • Age como o ponto de entrada de uma chamada inicial.
  • Age como um "retorno de chamada" da próxima autenticação de sucesso do OP.

Quando a chamada inicial for feita para acessar esta página, nenhum Wicket PageParameters é passado e o RP sabe que precisa verificar com o OP para autenticar o usuário.

RP executa descoberta

Para o RP e OP comunicarem-se, o RP precisa executar a descoberta no OP. Isto é simples do ponto de vista da codificação (novamente, a openid4java é a solução), mas é uma etapa importante e vou explicá-la aqui.

Este é o código que o RP usa (do construtor do OpenIdRegistrationPage) para enviar a solicitação de descoberta:

  DiscoveryInformation discoveryInformation =
    RegistrationService.performDiscoveryOnUserSuppliedIdentifier(
          OpenIdProviderService.getOpEndpointUrl());

Nesse código, o RP faz duas coisas:

  1. Executa a descoberta da Endpoint URL do OP.
  2. Associa-se com o OP. (Consultar a Parte 1 para obter uma explicação detalhada da troca de chaves de Diffie-Hellman e algumas das outras coisas interessantes que acontecem durante a associação.)

A seguir, depende do OP lidar com a solicitação de descoberta do RP.

OP responde à solicitação de descoberta

Lembre-se de que a openid4java está executando em ambos os lados RP e OP do exemplo de aplicativo. Assim, como parte do processo de descoberta com o OP, o lado RP da openid4java envia uma solicitação vazia à Endpoint URL do OP. A Endpoint URL é onde o OP é contatado e onde recebe todas as solicitações do RP. O OP deve ser configurado para lidar com esta solicitação. Se você olhar em OpenIdProviderService.getOpEndpointUrl(), você notará que a Endpoint URL é http://localhost:8080/openid-provider-sample-app/sample/OpenIdLoginPage.

Quando o RP envia a sua solicitação vazia ao OP, o Wicket constrói OpenIdLoginPage e executa seu construtor, mostrado na Listagem 2:

Listagem 2. O ponto de entrada de OP
 public OpenIdLoginPage(PageParameters parameters) throws IOException {
    super(parameters);
    if (parameters.isEmpty()) {
      // Empty request. Assume discovery request...
      OpenIdProviderService.sendDiscoveryResponse (getResponse());
  . . .

Observe que se o OP receber uma solicitação vazia, ele supõe que é uma solicitação de descoberta. Ele cria e envia de volta um documento XRDS ao solicitador.

A Listagem 3 mostra o código para sendDiscoveryRequest():

Listagem 3. Enviando de volta a resposta a uma solicitação de descoberta
  public static void sendDiscoveryResponse (Response response) throws IOException {
    //
    response.setContentType("application/xrds+xml");
    OutputStream outputStream = response.getOutputStream();
    String xrdsResponse = OpenIdProviderService.createXrdsResponse();
    //
    outputStream.write(xrdsResponse.getBytes());
    outputStream.close();
  }

O documento XRDS é vital para que o lado RP da openid4java funcione corretamente. Para ser sucinto, deixei os detalhes do documento fora deste artigo; para conhecer os detalhes, faça o download do código de origem do exemplo de aplicativo.

Quando o RP recebe o documento XRDS do OP, ele sabe que contatou o OP correto para aquele usuário. O RP então cria e envia a solicitação de autenticação ao OP.

RP solicita a autenticação do usuário

O RP verifica com o OP para assegurar que o usuário possa ser autenticado. A série de chamadas é mostrada na Listagem 4 (do construtor):

Listagem 4. RP codifica para delegar autenticação ao OP
  DiscoveryInformation discoveryInformation =
    RegistrationService.performDiscoveryOnUserSuppliedIdentifier(
          OpenIdProviderService.getOpEndpointUrl());
  MakotoOpenIdAwareSession session =
    (MakotoOpenIdAwareSession)getSession();
  session.setDiscoveryInformation(discoveryInformation, true);
  AuthRequest authRequest =
    RegistrationService.createOpenIdAuthRequest(
          discoveryInformation, 
          RegistrationService.getReturnToUrl());
  getRequestCycle().setRedirect(false);
  getResponse().redirect(authRequest.getDestinationUrl(true));

Primeiro, o RP contata o OP em sua Endpoint URL. Esta chamada pode parecer estranha, mas lembre-se de que neste cenário o foco é em um cluster de aplicativos que usa um parceiro confiável para agir como o OP. Do ponto de vista do RP, autenticar o identificador fornecido pelo usuário nada mais é do que descobrir o paradeiro do OP e deixar aopenid4java construir os objetos necessários para fazer com que as interações subsequentes sejam simples. O OP lidará com a mecânica da autenticação.

A seguir, a atual Sessão do Wicket é obtida e DiscoveryInformation obtida da openid4java é armazenada ali para uso posterior. Escrevi uma subclasse especial da Sessão denominada MakotoOpenIdAwareSession para facilitar o armazenamento de objetos openid4java na Sessão.

Depois disso, uma solicitação de autenticação é criada usando-se o objeto DiscoveryInformation obtido da openid4java. Este objeto é usado para informar ao Wicket para onde redirecionar para executar a chamada de autenticação.

Todas as etapas acima devem ser conhecidas da Parte 1. Repito-as aqui porque a arquitetura do código do exemplo de aplicativo usada neste artigo é consideravelmente diferente do código na Parte 1. Além disso, quero que você veja o lado OP das chamadas API e possa reuni-las.

Neste ponto, o RP está aguardando uma resposta de autenticação do OP. Antes de passarmos à próxima etapa, analisemos a função de Attribute Exchange na autenticação do usuário.

A extensão OpenID Attribute Exchange

Na primeira parte deste artigo, vimos sucintamente a extensão Simple Registration (SReg), que possibilita trocar um conjunto específico de informações, definido pela especificação SReg, entre RP e OP. Se você analisar o método createOpenIdAuthRequest() no exemplo de aplicativo deste artigo, notará que o RP usa outra extensão, OpenID Attribute Exchange (AX), para solicitar informações do OP.

A exemplo da extensão SReg, OpenID Attribute Exchange (AX) é usada para trocar informações entre RP e OP de modo padrão e uniforme. Ao contrário de SReg, AX deixa que os parceiros dependentes OpenID e provedores troquem informações ilimitadas, desde que ambos RP e OP sejam compatíveis com a extensão AX.

Em síntese, o RP pede ao OP informações específicas por meio de uma mensagem, e o OP envia essas informações de volta em uma mensagem. Essas mensagens são codificadas na URL à qual o navegador é direcionado, mas a openid4java usa objetos para tornar as informações disponíveis.

O RP usa uma classe denominada FetchRequest para fazer uma solicitação AX. Assim que ele tiver uma referência a este objeto de mensagem, ele adiciona os atributos que deseja que sejam retornados do OP, como mostrado na Listagem 5:

Listagem 5. O FetchRequest do RP com atributos
AuthRequest ret = obtainSomehow();
// Create AX request to get favorite color
FetchRequest fetchRequest = FetchRequest.createFetchRequest();
fetchRequest.addAttribute("favoriteColor",
       "http://makotogroup.com/schema/1.0/favoriteColor", 
        false); 
ret.addExtension(fetchRequest);

Quando o OP envia informações de volta ao RP, ele usa as mesmas construções, como mostrado na Listagem 6:

Listagem 6. O OP envia de volta os atributos solicitados
if (authRequest.hasExtension(AxMessage.OPENID_NS_AX)) {
  MessageExtension extensionRequestObject =
     authRequest.getExtension(AxMessage.OPENID_NS_AX);
  FetchResponse fetchResponse = null;
  Map<String, String> axData = new HashMap<String, String>();
  if (extensionRequestObject instanceof FetchRequest) {
   FetchRequest axRequest = (FetchRequest)extensionRequestObject;
    ParameterList parameters = axRequest.getParameters();
    fetchResponse = FetchResponse.createFetchResponse(
        axRequest, axData);
    if (parameters.hasParameter("type.favoriteColor")) {
       axData.put("favoriteColor", registrationModel.getFavoriteColor());
      fetchResponse.addAttribute("favoriteColor",
          "http://makotogroup.com/schema/1.0/favoriteColor",
          registrationModel.getFavoriteColor());
    }
      authResponse.addExtension(fetchResponse);
  } else {
    // ERROR
  }
}

Cada atributo que for definido tem ambos um nome simples e uma URL associada a ele. Neste caso, o nome simples do atributo é FavoriteColor e sua URL é http://makotogroup.com/schema/1.0/favoriteColor.

Além disso, o atributo deve ser capaz de ser transformado em sequências (ver o exemplo de aplicativo para conhecer um exemplo de enviar um campo de data dessa maneira). Quando definimos atributos para troca entre RP e OP, ambos têm que concordar com os atributos que são trocados; feito isso, o céu é o limite!

Agora, vamos continuar do ponto em que paramos com as interações de aplicativos.

OP autentica o usuário

No ponto em que paramos, a solicitação de autenticação tinha chegado à Endpoint URL do OP. Depois, o OP decifrará a solicitação para determinar o que fazer em seguida. O OP abre a solicitação para obter o seu modo, que pode ser associação ou autenticação.

Listagem 7. OP processa a solicitação de associação
//From (OpenIdLoginPage's constructor):

public OpenIdLoginPage(PageParameters parameters) throws IOException {
    super(parameters);
    . . .
    if ("associate".equals(mode)) {
        OpenIdProviderService.processAssociationRequest(getResponse(), requestParameters);
      }
    . . .
}

//From (OpenIdProviderService):

  public static void processAssociationRequest(Response response, ParameterList request) 
       throws IOException {
    Message message = getServerManager().associationResponse(request);
    sendPlainTextResponse(response, message);
  }
  private static void sendPlainTextResponse(Response response, Message message) 
       throws IOException {
    response.setContentType("text/plain");
    OutputStream os = response.getOutputStream();
    os.write(message.keyValueFormEncoding().getBytes());
    os.close();
  }

Na Listagem 7, o construtor de OpenIdLoginPage (que é o ponto de entrada para o OP no exemplo de aplicativo) primeiro decifra a solicitação. O modo indica uma solicitação de associação; por isso, ele delega a mecânica da associação à openid4java, cujo código é quebrado em OpenIdProviderService.java. A solicitação de associação é enviada de volta ao RP.

Assim que RP estiver satisfeito com o fato de que a associação foi estabelecida (na verdade, assim que a openid4java estiver satisfeita) o RP faz outra chamada ao OP. Novamente, o OP decifra a solicitação e a processa. Na maioria das vezes, será uma solicitação checkid_authentication.

A Listagem 8 mostra o código do construtor de OpenIdLoginPage:

Listagem 8. openid4java decifra a solicitação checkid_authentication
  public OpenIdLoginPage(PageParameters parameters) throws IOException {
    super(parameters);
     . . .
      else if ("checkid_immediate".equals(mode)
    		  ||
    		   "checkid_setup".equals(mode)
    		  ||
    		   "check_authentication".equals(mode)) {
        if (((MakotoOpenIdAwareSession)getSession()).isLoggedIn()) {
          // Create AuthResponse from session variables...
         sendSuccessfulResponse();
        }
    add(new OpenIdLoginForm("form"));
    . . 
  }

Observe as duas linhas em negrito na Listagem 8. Na primeira linha em negrito, OpenIdLoginPage envia de volta uma solicitação com sucesso. Primeiro, OpenIdLoginPage usa um objeto Sessão para determinar se o usuário está conectado ou não (um usuário conectado não terá que fazer login novamente). Se o usuário estiver conectado, ele retorna uma mensagem de autenticação de sucesso. É assim que se consegue o logon único no exemplo de aplicativo.

Se o usuário não estiver conectado, o Wicket cria um formulário de login no qual o usuário pode digitar as suas credenciais, como mostrado na Figura 2:

Figura 2. O OP exibe uma tela de login para um usuário não autenticado
O OP exibe uma tela de login para um usuário não autenticado

Se o usuário for autenticado com sucesso, ele recebe de volta uma resposta de sucesso, e algumas informações — específicas do objetoDiscoveryInformation— são armazenadas na Sessão. Mais uma vez, esta é a mecânica subjacente da autenticação com logon único.

Neste ponto, o navegador é redirecionado à URL "retornar para" do RP com uma resposta de autenticação de sucesso.

RP concede acesso

Se o usuário efetuou login com sucesso, o OP envia de volta uma mensagem AuthResponse de sucesso. Agora, depende do RP conceder acesso ao usuário. O exemplo de aplicativo automaticamente concede acesso se o usuário for autenticado pelo OP. Além disso, o OP envia todas as informações que o RP solicitou sobre o usuário. Na Figura 3, o RP exibe as informações na sua tela de registro:

Figura 3. A página de registro do exemplo de aplicativo que mostra informações recuperadas do OP
A página de registro do exemplo de aplicativo que mostra informações recuperadas do OP

Conclusão

Neste artigo, você viu como usar a especificação OpenID Authentication para configurar autenticação única do usuário para um cluster de aplicativos parceiros. Uma arquitetura de logon único funciona quando se estabeleceu confiança entre os aplicativos parceiros e um parceiro age como o OpenID Provider (OP).

Usar OpenID para autenticação e troca de dados garante que todos os participantes concordam com os termos de autenticação e autorização. Porque OpenID é um padrão amplamente adotado, novos seguidores também encontrarão considerável apoio do setor para conhecer e resolver problemas das implementações de OpenID Authentication .

Analise o exemplo de código se você quiser saber mais sobre a arquitetura de único logon implementada neste artigo. Basta construir o WAR, jogá-lo no Tomcat e executá-lo! Não se esqueça de ativar a criação de logs de RASTREIO e observar o resultado do log, que revela detalhes do aplicativo não discutidos no artigo.

Como qualquer especificação, a OpenID Authentication é complexa, mas a openid4java a simplifica muito. Faça o download do código de origem deste artigo e use-o para auxiliar na autenticação dos seus aplicativos com OpenID.


Download

DescriçãoNomeTamanho
Source code for the sample applicationopenid-provider-sample-app.zip4.5KB

Recursos

Aprender

Obter produtos e tecnologias

Discutir

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Tecnologia Java, Software livre
ArticleID=480767
ArticleTitle=OpenID para aplicativos Java Web, Parte 2: Escrever um OpenID Provider para autenticação única
publish-date=04062010