Por que eu devo ler este artigo:O presente artigo trata de questões de usabilidade em aplicativos sensíveis ao contexto, tendo como principal objetivo o aprimoramento da experiência do usuário, exemplificando e conceituando algumas questões (controle, inteligibilidade, privacidade e sobrecarga de informação) que devem ser consideradas ao se criar esse determinado tipo de aplicativo. A discussão desse tema é útil pois seu entendimento e correta aplicação contribui para tornar os aplicativos mais fáceis de usar e autônomos, provendo mecanismos que diminuam a interação do usuário com o celular. A ideia principal é disseminar e motivar a utilização da sensibilidade ao contexto em aplicativos, evidenciando o potencial efeito dessa tecnologia para o aprimoramento da experiência do usuário.

O módulo de autenticação de usuários presente nos sistemas é, certamente, um assunto recorrente nas discussões sobre segurança da informação. É recomendado que seja definida e planejada toda a parte de autenticação e identificação de usuários logo no início de um projeto, ou até mesmo antes de ele ser iniciado, já que, com certeza, ele poderá influenciar de modo geral o projeto. A implementação tardia dessa etapa crucial da maioria dos aplicativos pode trazer muito impacto ao desenvolvimento já existente.

A autenticação de usuários pode ser realizada de diferentes modos, mas este artigo contemplará os conceitos básicos da autenticação e apenas dois tipos: baseada em Adapters JavaScript e baseada em Adapters Java. Os outros tipos de autenticação, não muito comuns, são: Form-based, Header-based, LDAP e LTPA. O desenvolvimento de um sistema de autenticação requer implementação do lado do servidor, mais especificamente em Adapters escritos em JavaScript ou em Java. Além disso, é necessária a implementação do lado cliente, que seria responsável pelo envio das credenciais e eventos da autenticação.

Os Adapters baseados em JavaScript somam a facilidade e flexibilidade de se desenvolver em JavaScript com os recursos poderosos da API Java. Esse recurso usa a engine chamada Rhino (veja a seção Links) para rodar os adapters escritos como scripts JavaScript em um servidor Java, como WebSphere ou Tomcat.

Os Adapters baseados em Java são um dos recursos adicionados à versão 7.0 do IBM MobileFirst Platform. E não estamos falando apenas de chamadas a código Java, como já era possível desde as primeiras versões da plataforma, estamos falando de adapters escritos totalmente em Java, seguindo a especificação Java EE para serviços RESTful, JAX-RS (veja a seção Links).

É recomendável ter um conhecimento básico dos dois tipos de implementação, Adapters escritos em JavaScript e Adapters escritos em Java, para decidir qual das duas vias atende melhor aos requisitos da implementação da autenticação de usuários no projeto. Nesse sentido, é importante também conhecer os conceitos centrais da autenticação e identificação de usuários no IBM MobileFirst, uma vez que eles podem impactar na escolha da tecnologia a ser usada.

Os termos chave usados pela plataforma IBM MobileFirst para essa etapa no desenvolvimento de aplicativos, e que poderiam ajudar na busca de maiores informações e detalhes técnicos, são (ver Figura 1): Realm, Security Test, Authenticator, Login Module, User Identity e Challenge Handler. Esse último faz parte da implementação client-side. Ao longo do artigo, cada um desses termos, seus objetivos e usos, serão esclarecidos.

Estrutura
do IBM MobileFirst
Figura 1. Estrutura do IBM MobileFirst

Security-test

Do lado do servidor, o security-test age como o porteiro da entrada das requisições. Através dele, definimos que determinada procedure ou resource só será acessado caso passe no teste de autenticação, ou seja, caso o usuário que realize a requisição já esteja autenticado no aplicativo. Nele identificamos o Realm, que irá fornecer a resposta para as perguntas: "Esse usuário tem acesso a esse recurso? Esse usuário está autenticado no Realm em questão?".

Para proteger procedures de Adapters JavaScript, basta adicionar o atributo "securityTest" na procedure a ser protegida no XML de configuração do Adapter:

<procedure name="procedureQueApenasUsuariosLogadosTemAcesso" 
securityTest="RevendedorLoginRealm-securityTest"/>

O securityTest é criado anteriormente no XML de configuração de autenticação do servidor, chamado authenticationConfig.xml, como no exemplo da Listagem 1.

Listagem 1. Arquivo authenticationConfig.xml

<securityTests>
  <customSecurityTest name="RevendedorLoginRealm-securityTest">
  <test isInternalUserID="true" realm="RevendedorLoginRealm"/>
  </customSecurityTest>
  ...
  </securityTests>

Também é possível proteger recursos estáticos através de um securityTest. Por exemplo, a interface de administração do IBM MobileFirst Platform é protegida por um securityTest e um Realm interno da plataforma (ver ...

Quer ler esse conteúdo completo? Tenha acesso completo