Red Hat SummitCapítulo 12. Módulos de Logon
12.1. Módulos de Uso
Copiar o linkLink copiado para a área de transferência!
A Plataforma do Aplicativo JBoss Enterprise inclui diversos módulos úteis de logon agrupados à maioria das necessidades de gerenciamento do usuário. A Plataforma do Aplicativo JBoss Enterprise pode ler informação do usuário a partir de banco de dados relacionais, um servidor do Protocolo de Acesso do Diretório de Carga Leve - Lightweight Directory Access Protocol (LDAP) ou arquivos simples. Adicionados aos módulos de logon principais, o JBoss fornece outros módulos de logon que fornecem a informação do usuário para as mais personalizadas necessidades no JBoss.
12.1.1. LdapLoginModule
Copiar o linkLink copiado para a área de transferência!
O
LdapLoginModule é uma implantação LoginModule que autentica o servidor do Protocolo de Acesso ao Diretório de Peso Leve (LDAP - Lightweight Directory Access Protocol), caso seu nome de usuário e credenciais estejam armazenados num servidor LDAP que é acessado usando um provedor LDAP da Interface do Diretório e Nomeação do Java (JNDI).
Nota
Este módulo de logon suporta também a identidade não-autenticada e o empilhamento da senha.
A informação de conectividade do LDAP é fornecida como opções de configuração que são passadas através do objeto do ambiente usado para criar o contexto inicial do JNDI. As propriedades JNDI do LDAP padrão usadas incluem o seguinte:
- java.naming.factory.initial
- O nome da classe de implantação
InitialContextFactory. O padrão é a implantação do provedor LDAP do Suncom.sun.jndi.ldap.LdapCtxFactory. - java.naming.provider.url
- O URL do LDAP para o servidor LDAP.
- java.naming.security.authentication
- O nível do protocolo para uso. Os valores disponíveis incluem o
none,simpleestrong. Caso a propriedade seja indefinida, o comportamento é determinado pelo provedor do serviço. - java.naming.security.protocol
- O protocolo de transporte para uso de acesso de segurança. Configure a opção de configuração ao tipo do provedor do serviço (por exemplo: o SSL). Caso a propriedade seja indefinida, o comportamento será determinado pelo provedor do serviço.
- java.naming.security.principal
- Especifica a identidade do Principal para autenticação do chamador ao serviço. Ele é construído a partir de outras propriedades conforme descrito abaixo.
- java.naming.security.credentials
- Especifica os credenciais do Principal para autenticação do chamador ao serviço. Os credenciais podem levar o modelo de uma senha com hash, uma senha de texto simples, uma chave ou um certificado. Caso a propriedade for indefinida, o comportamento é determinado pelo provedor do serviço.
As opções da configuração do módulo do logon suportado incluem o seguinte:
- principalDNPrefix
- O prefixo adicionado ao nome do usuário para formar o distinguished name do usuário. Consulte
principalDNSuffixpara maiores informações. - principalDNSuffix
- O sufixo adicionado ao nome do usuário quando formando o nome distinguido do usuário. Ele é útil caso você solicite pelo nome do usuário e não queira que o usuário insira o todo o nome distinguido. O uso desta propriedade e
principalDNSuffixleva ouserDNa ser formado comoprincipalDNPrefix + username + principalDNSuffix. - useObjectCredential
- O valor que indica o credencial deve ser obtido como um
Objectopaco usando o tipo doorg.jboss.security.auth.callback.ObjectCallbackdoCallbackao invés de uma senhachar[]usando umPasswordCallbackdo JAAS. Isto permite a passagem da informação sem-credencial para o servidor LDAP. Os valores disponíveis sãotrueefalse. - rolesCtxDN
- Ajustado, o nome distinguido do contexto para busca das funções do usuário.
- userRolesCtxDNAttributeName
- Nome de um atributo no objeto do usuário que contém o nome distinguido do contexto para busca das funções do usuário. Isto difere-se do
rolesCtxDN, de forma que o contexto de busca para funções do usuário pode ser único para cada usuário. - roleAttributeID
- Nome do atributo contendo as funções do usuário. O padrão é
roles, caso não seja especificado. - roleAttributeIsDN
- Aviso indicando se é que o roleAttributeID contém todo o nome distinguido de um objeto de função, ou o nome de função. O nome de função é obtido do valor do atributo roleNameAttributeId do nome do contexto pelo nome distinguido.Caso verdadeiro, o atributo da função representa o nome distinguido de um objeto de função. Caso seja falso, o nome de função é obtido a partir do valor de um
roleAttributeID. O padrão éfalse.Nota
Em certos esquemas de diretório (ex.: MS ActiveDirectory), os atributos de função no objeto do usuário são armazenados como Nomes Distinguidos para objetos de função ao invés de nomes simples. O roleAttributeIsDN deve ser configurado paratrue, para implantações que usam este tipo de esquema. - roleNameAttributeID
- O nome do atributo de um contexto direcionado pelo valor do nome distinguido roleCtxDN que contém o nome de função. Caso a propriedade roleAttributeIsDN seja configurada para
true, esta propriedade será usada para encontrar o atributonamedo objeto de função. O padrão égroup. - uidAttributeID
- Nome do atributo no objeto contento as funções do usuário que correspondem à ID do usuário. Isto é usado para localizar as funções do usuário. O padrão é
uid, caso não seja especificado. - matchOnUserDN
- Aviso que especifica se é que a busca por funções do usuário devem coincidir com todo o nome distinguido do usuário. Caso
true, ouserDNcompleto será usado como valor de combinação. Casofalse, apenas o nome do usuário será usado como valor de combinação em relação ao atributo uidAttributeName. O valor padrão éfalse. - unauthenticatedIdentity
- O nome principal a ser determinado sem conter qualquer informação de autenticação. Este comportamento é herdado a partir da super-classe
UsernamePasswordLoginModule. - allowEmptyPasswords
- Um aviso indicando se as senhas nulas (comprimento 0) devem ser passadas ao servidor LDAP. Uma senha vazia é tratada como um logon anônimo por alguns servidores LDAP e isto pode não ser um recurso desejado. Para rejeição de senhas nulas, configure isto para
false. Caso configurado paratrue, o servidor LDAP validará a senha nula. O padrão étrue.
A autenticação do usuário é executada pela conexão ao servidor LDAP, baseado nas opções de configuração do módulo de logon. A conexão ao servidor LDAP é realizada pela criação de um
InitialLdapContext com um ambiente composto de propriedades JNDI do LDAP descritas anteriormente nesta seção.
O Context.SECURITY_PRINCIPAL é configurado ao nome distinguido do usuário obtido pelo manuseador da chamada de retorno em combinação com os valores de opção principalDNPrefix e principalDNSuffix. Além disso, a propriedade Context.SECURITY_CREDENTIALS é tanto configurada à senha
String ou o credencial Object dependendo da opção useObjectCredential.
Uma vez que a autenticação tenha sido bem sucedida (a instância
InitialLdapContext é criada), as funções do usuário são solicitadas pela execução de uma busca da localização rolesCtxDN com os atributos determinados para os valores de opção roleAttributeName e uidAttributeName. Os nomes de função são obtidos pela invocação do método toString nos atributos de função do conjunto do resultado de busca.
Exemplo 12.1. Política da Autenticação do Módulo do Logon LDAP
Esta política de autenticação descreve como usar os parâmetros na política de autenticação do domínio de segurança.
As opções
java.naming.factory.initial, java.naming.factory.url e java.naming.security da configuração testLDAP <login-module> indicam as condições:
- A implantação do provedor JNDI do LDAP Sun será usada.
- O servidor LDAP está localizado no
ldaphost.jboss.orgdo host na porta 1389. - O método de autenticação simples do LDAP será usado para conexão ao servidor LDAP.
O módulo do logon tenta conectar-se ao servidor LDAP usando um Nome Distinguido (DN) representando o usuário pelo qual está tentando autenticar. Este DN é construído a partir do principalDNPrefix passado, o nome do usuário e o principalDNSuffix, conforme descritos acima. No Exemplo 12.2, “Amostra do Arquivo LDIF”, o nome do usuário
jsmith mapearia para uid=jsmith,ou=People,dc=jboss,dc=org.
- Nome Distinguido (DN)
- Num Protocolo de Acesso ao Diretório de Carga Leve (LDAP), o nome distinguido identifica unicamente um objeto num diretório. Cada nome distinguido deve possuir um nome e localização únicos a partir de todos os objetos, que é atingido usando um número de pares de valor do atributo (AVPs). Os AVPs definem informações tais como nomes comuns, unidade de organização, entre outras coisas. A combinação desses valores resulta numa sequência única solicitada pelo LDAP.
Nota
A amostra assume que o servidor LDAP autentica os usuários usando o atributo
userPassword da entrada do usuário (theduke nesta amostra). A maioria dos servidores LDAP operam desta maneira. No entanto, caso o servidor LDAP manuseia autenticações de forma diferente, você deverá certificar-se que o LDAP é configurado de acordo com suas solicitações do ambiente de produção.
Uma vez que a autenticação é bem sucedida, as funções pelas quais a autorização será baseada são restauradas pela execução da busca da sub-árvore do
rolesCtxDN para entradas cujos uidAttributeID coincidem com o usuário. Caso o matchOnUserDN seja verdadeiro, a busca será baseada no DN completo do usuário. Do contrário, a busca será baseada no nome do usuário atual inserido. Nesta amostra, a busca está sob o ou=Roles,dc=jboss,dc=org para quaisquer entradas que possuem o atributo member ao uid=jduke,ou=People,dc=jboss,dc=org. A busca localizaria o cn=JBossAdmin sob a entrada das funções.
A busca retorna o atributo especificado na opção roleAttributeID. Nesta amostra, o atributo é o
cn. O valor retornado seria o JBossAdmin, de forma que o usuário jsmith é determinado à função do JBossAdmin.
O servidor LDAP local normalmente fornece serviços de identidade e localização, mas não está apto a usar os serviços de autorização. Isto é devido às funções do aplicativo nem sempre mapearem bem os grupos LDAP e os administradores LDAP normalmente hesitarem em permitir os dados específicos do aplicativo externo nos servidores LDAP centrais. O módulo de autenticação LDAP é normalmente emparelhado com outro módulo de logon, que pode fornecer funções mais úteis ao aplicativo sendo desenvolvido.
O arquivo do Formato de Inter-alteração dos Dados LDAP (LDIF) representando a estrutura do diretório que esses dados operam, está apresentado no Exemplo 12.2, “Amostra do Arquivo LDIF”.
- Formato de Inter-alteração dos Dados LDAP (LDIF)
- O formato de inter-alteração de dados planos usados para representar o conteúdo do diretório LDAP e solicitações de atualização. O conteúdo do diretório é representado como uma gravação para cada solicitação de atualização e objeto. O conteúdo consiste na adição, renomeação, remoção, modificação das solicitações.
Exemplo 12.2. Amostra do Arquivo LDIF
12.1.2. Empilhamento da Senha
Copiar o linkLink copiado para a área de transferência!
Os módulos de logon podem ser encadeados numa pilha, com cada módulo de logon fornecendo ambos componentes de autorização e autenticação. Isto funciona em muitos casos, mas às vezes a autenticação e autorização são divididas em múltiplos armazenamentos de gerenciamento do usuário.
A Seção 12.1.1, “LdapLoginModule” descreve como combinar um LDAP e o banco de dados relacional, permitindo um usuário a ser autenticado por qualquer sistema. No entanto, considere o caso onde os usuários são gerenciados num servidor LDAP central, mas as funções específicas do aplicativo são armazenadas no banco de dados do aplicativo. A opção do módulo de pilha da senha captura essa relação.
Para uso da pilha da senha, cada módulo de logon deve configurar o atributo <module-option>
password-stacking para useFirstPass. Caso um módulo anterior configurado para a pilha da senha tenha autenticado o usuário, todos os demais módulos de pilha considerarão o usuário autenticado e apenas tentarão fornecer um conjunto de funções para a etapa de autorização.
Quando a opção
password-stacking for configurada para useFirstPass, este módulo observa primeiro por um nome e senha compartilhados sob os nomes de propriedade javax.security.auth.login.name e javax.security.auth.login.password respectivamente no mapa do estado compartilhado do módulo de logon.
Caso encontradas, essas propriedades são usadas como o nome e senha principal. Caso não encontradas, a senha e nome principal são configurados por esse módulo de logon e armazenados sob os nomes de propriedade javax.security.auth.login.name e javax.security.auth.login.password respectivamente.
Nota
Quando usando a pilha da senha, configure todos os módulos a serem solicitados. Isto garante que todos os módulo são considerados e possuem a chance de contribuir funções ao processo de autorização.
Exemplo 12.3. Amostra da Pilha da Senha
Essa amostra apresenta como a pilha de senha pode ser usada.
12.1.3. Aplicação do Hash na Senha
Copiar o linkLink copiado para a área de transferência!
A maioria dos módulos de logon devem comparar uma senha suprida por um cliente com uma senha armazenada num sistema de gerenciamento do usuário. Esses módulos normalmente trabalham com as senhas de texto plano, mas podem ser configurados para suportar as senhas com hash para prevenir textos planos de serem armazenados ao lado do servidor.
Exemplo 12.4. Aplicação do Hash na Senha
A seguinte configuração do módulo de logon determina aos usuários não-autenticados o
nobody de nome principal e contém o based64-encoded, hashes MD5 das senhas num arquivo usersb64.properties. O arquivo usersb64.properties pode fazer parte de um classpath de implantação ou ser salvo no diretório /conf.
- hashAlgorithm
- O nome do algoritmo
java.security.MessageDigestpara aplicar o hash na senha. Não existe padrão, de forma que a opção deve ser especificada para ativar o hash. Os valores típicos sãoMD5eSHA. - hashEncoding
- A sequência especifica um dos três tipos de codificação:
base64,hexourfc2617. O padrão ébase64. - hashCharset
- O conjunto de caractere de codificação usado para converter a senha de texto simples a um array de byte. A codificação do padrão da plataforma é o padrão.
- hashUserPassword
- Especifica que o algorismo hash deve ser aplicado à senha que o usuário submete. A senha do usuário com hash é comparada ao valor no módulo de logon, que espera-se ser um hash da senha. O padrão é
true. - hashStorePassword
- Especifica que o algorismo hash deve ser aplicado à senha armazenada ao lado do servidor. Isto é usado para resumir a autenticação, onde o usuário submete um hash da senha do usuário com os tokens específicos de solicitação a partir do servidor a ser comparado. O algorismo hash (para resumir, isto seria
rfc2617) é utilizado para computar o hash ao lado do servidor, que deve coincidir o valor com hash enviado a partir do cliente.
Caso você precise gerar senhas em código, a classe
the org.jboss.security.Util fornece um método de ajuda estático que efetuará o hash numa senha usando a codificação especificada.
String hashedPassword = Util.createPasswordHash("MD5",
Util.BASE64_ENCODING, null, null, "password");
String hashedPassword = Util.createPasswordHash("MD5",
Util.BASE64_ENCODING, null, null, "password");
O OpenSSL fornece uma forma alternativa de gerar senhas com hash.
echo -n password | openssl dgst -md5 -binary | openssl base64
echo -n password | openssl dgst -md5 -binary | openssl base64
Em ambos os casos, a senha de texto deve efetuar o hash para
X03MO1qnZdYdgyfeuILPmQ==. Este valor deve ser armazenado num armazenamento do usuário.
12.1.4. Identidade não-autenticada
Copiar o linkLink copiado para a área de transferência!
Perceba que todas as solicitações são recebidas num formato autenticado. O
unauthenticated identity é uma opção de configuração do módulo de logon que determina uma identidade específica (convidado, por exemplo) para solicitações que são feitas com a informação não associada. Isto pode ser usado para permitir os servlets não-protegidos para invocar os métodos no EJBs que não requerem uma função específica. Tal principal não possui funções associadas e pode apenas associar tanto os métodos EJB ou EJBs não assegurados que são associados com a restrição de permissão não selecionada.
- unauthenticatedIdentity: define o nome principal que deve ser determinado para solicitações que não contém a informação de autenticação.
12.1.5. UsersRolesLoginModule
Copiar o linkLink copiado para a área de transferência!
O
UsersRolesLoginModule é um módulo de logon que suporta usuários múltiplos e funções de usuários carregadas de arquivos de propriedades Java. O arquivo de mapeamento nome-para-senha do usuário é chamado users.properties e o arquivo de mapeamento de nome-para-funções é chamado roles.properties.
As opções de configuração do módulo de logon suportadas incluem o seguinte:
- usersProperties
- Nome do recurso (arquivo) de propriedades contendo o nome do usuário para mapeamentos de senha. O padrão é
<filename_prefix>-users.properties. - rolesProperties
- Nome do recurso (arquivo) de propriedades contendo o nome de usuário para mapeamentos de funções. O padrão é
<filename_prefix>-roles.properties.
O modelo de logon suporta o empilhamento da senha, a aplicação do hash na senha e a identidade não-autenticada.
Os arquivos de propriedades são localizados durante a inicialização usando o carregador de classe do contexto de segmentação do método iniciar. Isto significa que esses arquivos podem ser posicionados no JAR de implantação do Java EE, o diretório de configuração do JBoss ou qualquer diretório do servidor do JBoss ou classpath do sistema. O propósito primário deste módulo de logon é testar facilmente as configurações de segurança de usuários múltiplos e funções usando os arquivos de propriedade com o aplicativo.
Exemplo 12.5. UserRolesLoginModule
O arquivo
ejb3-sampleapp-users.properties no Exemplo 12.5, “UserRolesLoginModule” usa o formato username=password com cada entrada de usuário numa linha separada:
username1=password1 username2=password2 ...
username1=password1
username2=password2
...
O arquivo
ejb3-sampleapp-roles.properties referenciado no Exemplo 12.5, “UserRolesLoginModule” usa o username=role1,role2, padrão com o valor do nome do grupo opcional. Por exemplo:
username1=role1,role2,... username1.RoleGroup1=role3,role4,... username2=role1,role3,...
username1=role1,role2,...
username1.RoleGroup1=role3,role4,...
username2=role1,role3,...
O nome da propriedade user name.XXX padrão presente no
ejb3-sampleapp-roles.properties é usado para determinar as funções do nome do usuário para o grupo nomeado em particular onde a porção XXX do nome da propriedade é o nome do grupo. O formulário user name=... é uma abreviação para user name.Roles=..., onde o nome do grupo Roles é um nome padrão que o JaasSecurityManager espera conter as funções que definem permissões aos usuários.
Segue abaixo as definições equivalentes para o nome de usuário
jduke:
jduke=TheDuke,AnimatedCharacter jduke.Roles=TheDuke,AnimatedCharacter
jduke=TheDuke,AnimatedCharacter
jduke.Roles=TheDuke,AnimatedCharacter12.1.6. DatabaseServerLoginModule
Copiar o linkLink copiado para a área de transferência!
O
DatabaseServerLoginModule é o módulo do logon na Conectividade do Banco de Dados do Java - Java Database Connectivity (JDBC) que suporta a autenticação e o mapeamento da função. Use este módulo de logon caso você possua o nome do usuário, senha e informação da função armazenada num banco de dados relacional.
Nota
Este módulo suporta o empilhamento da senha, a aplicação do hash na senha e a identidade não-autenticada.
O
DatabaseServerLoginModule é baseado em duas tabelas lógicas:
Table Principals(PrincipalID text, Password text) Table Roles(PrincipalID text, Role text, RoleGroup text)
Table Principals(PrincipalID text, Password text)
Table Roles(PrincipalID text, Role text, RoleGroup text)
A tabela
Principals associa o PrincipalID do usuário com a senha válida e a tabela Roles associa o PrincipalID do usuário com os próprios conjuntos de funções. As funções usadas para permissões do usuário devem estar contidas em filas com um valor de coluna RoleGroup do Roles.
As tabelas são lógicas de forma que você pode especificar a solicitação SQL que o módulo de logon usa. A única solicitação é que o
java.sql.ResultSet possua a mesma estrutura lógica às das tabelas Principals e Roles descritas anteriormente. Os nomes atuais das tabelas e colunas não são relevantes uma vez que os resultados são acessados baseando-se no índice da coluna.
Para melhor entendimento desta noção, considere um banco de dados com duas tabelas,
Principals e Roles, conforme já declarado. As seguintes declarações preenchem as tabelas com os seguintes dados:
- O
PrincipalIDjavacom oPassworddoechomanna tabelaPrincipals. - O
PrincipalIDjavacom a função nomeadaEchonoRolesRoleGroupda tabelaRoles. - O
PrincipalIDjavacom a função nomeadacaller_javanoCallerPrincipalRoleGroupda tabelaRoles.
INSERT INTO Principals VALUES('java', 'echoman')
INSERT INTO Roles VALUES('java', 'Echo', 'Roles')
INSERT INTO Roles VALUES('java', 'caller_java', 'CallerPrincipal')
INSERT INTO Principals VALUES('java', 'echoman')
INSERT INTO Roles VALUES('java', 'Echo', 'Roles')
INSERT INTO Roles VALUES('java', 'caller_java', 'CallerPrincipal')
As opções de logon suportadas incluem o seguinte:
- dsJndiName
- O nome do JNDI para o
DataSourcedo banco de dados contendo as tabelasPrincipalseRoles. O padrão éjava:/DefaultDS, caso não seja especificado. - principalsQuery
- A consulta de declaração preparada é equivalente a:
select Password from Principals where PrincipalID=?. Essa será a declaração preparada utilizada, caso não seja especificada. - rolesQuery
- A consulta de declaração preparada é equivalente a:
select Role, RoleGroup from Roles where PrincipalID=?. Essa será a declaração preparada utilizada, caso não seja especificada. - ignorePasswordCase
- Um aviso boolean indicando se a comparação de senha deve ignorar o caso. Isto pode ser útil para a codificação de senha com hash onde o caso da senha com não é significativo.
- principalClass
- Uma opção que especifica uma classe de implementação
Principal. Isto deve suportar um construtor levando um argumento de sequência para o nome principal.
Uma amostra da configuração
DatabaseServerLoginModule pode ser construída conforme abaixo:
CREATE TABLE Users(username VARCHAR(64) PRIMARY KEY, passwd VARCHAR(64)) CREATE TABLE UserRoles(username VARCHAR(64), userRoles VARCHAR(32))
CREATE TABLE Users(username VARCHAR(64) PRIMARY KEY, passwd VARCHAR(64))
CREATE TABLE UserRoles(username VARCHAR(64), userRoles VARCHAR(32))
Uma entrada
login-config.xml correspondente parece-se com o seguinte:
12.1.7. BaseCertLoginModule
Copiar o linkLink copiado para a área de transferência!
O
BaseCertLoginModule autentica usuários baseados nos certificados X509. Um caso típico de uso para o módulo de logon é a autenticação CLIENT-CERT na camada da web.
Este módulo de logon executa apenas autenticação. Você deverá combinar isto com outro módulo de logon capaz de adquirir as funções de autorização para definir completamente o acesso à web protegida ou componente EJB. As duas sub-classes deste módulo de logon,
CertRolesLoginModule e DatabaseCertLoginModule estendem o comportamento para obter as funções de autorização de ambos banco de dados ou arquivo de propriedades.
O
BaseCertLoginModule precisa de um KeyStore para executar a validação do usuário. Isto é obtido através de uma implantação org.jboss.security.SecurityDomain. Normalmente, a implantação SecurityDomain é configurada usando o org.jboss.security.plugins.JaasSecurityDomain MBean conforme apresentado neste fragmento de configuração jboss-service.xml:
A configuração cria um domínio de segurança com o
jmx-console do nome, com uma implantação SecurityDomain disponível através do JNDI sob o java:/jaas/jmx-console do nome. O domínio de segurança segue o padrão de nomeamento do domínio de segurança do JBossSX.
Procedimento 12.1. Proteção dos Aplicativos da Web com os Certificados e Autorização baseada na Função
Este procedimento descreve como proteger um aplicativo da web, tal como o
jmx-console.war, usando os certificados de cliente e a autorização baseada da função.
Declaração dos Recursos e Funções
Modifique oweb.xmlpara declarar os recursos a serem protegidos com as funções permitidas e domínio de segurança a serem usados para a autenticação e autorização.Copy to Clipboard Copied! Toggle word wrap Toggle overflow Especificação do Domínio de Segurança do JBoss
Especifique o domínio de segurança solicitado nojboss-web.xml.<jboss-web> <security-domain>jmx-console</security-domain> </jboss-web>
<jboss-web> <security-domain>jmx-console</security-domain> </jboss-web>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Especificação da Configuração do Módulo de Logon
Define a configuração do módulo de logon para o domínio de segurança do jmx-console que você acabou de especificar. Isto é realizado no arquivoconf/login-config.xml.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
O Procedimento 12.1, “Proteção dos Aplicativos da Web com os Certificados e Autorização baseada na Função” que apresenta o
BaseCertLoginModule é usado para autenticação do cert do cliente e o UsersRolesLoginModule é apenas usado para a autorização devido à opção password-stacking=useFirstPass. Ambos os localhost.keystore e jmx-console-roles.properties requerem uma entrada que mapeia o associado principal ao cert do cliente.
Por padrão, o principal é criado usando o nome distinguido do certificado do cliente, tal como o DN especificado no Exemplo 12.6, “Amostra de Certificado”.
Exemplo 12.6. Amostra de Certificado
O
localhost.keystore precisa do certificado no Exemplo 12.6, “Amostra de Certificado” armazenado com um alias do CN=unit-tests-client, OU=JBoss Inc., O=JBoss Inc., ST=Washington, C=US. O jmx-console-roles.properties também precisa de uma entrada para a mesma entrada. Uma vez que o DN contém caracteres que são normalmente tratados como delimitadores, você deverá fugir do problema com caracteres usando uma barra invertida ('\'), conforme ilustrado abaixo.
Um arquivo roles.properties de amostra para uso com o UsersRolesLoginModule
# Um arquivo roles.properties de amostra para uso com o UsersRolesLoginModule
CN\=unit-tests-client,\ OU\=JBoss\ Inc.,\ O\=JBoss\ Inc.,\ ST\=Washington,\ C\=US=JBossAdmin
admin=JBossAdmin12.1.8. IdentityLoginModule
Copiar o linkLink copiado para a área de transferência!
O
IdentityLoginModule é um módulo de logon\nsimples que associa o nome do usuário de código rígido a qualquer assunto autenticado em relação ao módulo. Ele cria uma instância SimplePrincipal usando o nome especificado pela opção principal.
Nota
Este módulo suporta o empilhamento de senha.
Este módulo de logon é útil quando você precisar fornecer uma identidade fixa a um serviço, e em ambientes de desenvolvimento quando você desejar testar a segurança associada com as funções associadas e um principal gerado.
As opções de configuração do módulo de logon incluem:
- principal
- Este é o nome a ser usado no
SimplePrincipal, sendo que todos os usuários são autenticados como tal. O padrão do nome principal éguest, caso nenhuma opção do principal seja especificada. - funções
- Esta é a lista de vírgula delimitada das funções que serão determinadas ao usuário.
Segue abaixo uma amostra da entrada de configuração XMLLoginConfig. A entrada autentica todos os usuários como o principal nomeado
jduke e determina os nomes de função determinados do TheDuke e AnimatedCharacter:
12.1.9. RunAsLoginModule
Copiar o linkLink copiado para a área de transferência!
O
RunAsLoginModule (org.jboss.security.auth.spi.RunAsLoginModule) é um módulo de ajuda que envia uma execução como função na pilha durante a fase de logon de autenticação, além de lançar a execução como função tanto na fase de confirmação ou abortação.
O propósito deste módulo de logon é fornecer uma função dos módulos de logon que devem acessar os recursos protegidos, com o objetivo de executar a própria autenticação (por exemplo, o módulo de logon que acessa um EJB protegido). O
RunAsLoginModule deve ser configurado antes dos módulos de logon que requerem uma execução como função estabelecida.
A única opção de configuração do módulo de logon é a seguinte:
- roleName
- Nome da função para uso como a execução durante a fase de logon. Caso não especificado, o padrão do
nobodyserá usado.
12.1.10. Criação do RunAsIdentity
Copiar o linkLink copiado para a área de transferência!
Com o objetivo da Plataforma do Aplicativo JBoss Enterprise proteger o acesso aos métodos EJB, a identidade do usuário deve ser conhecida no momento em que a chamada do método é realizada.
A identidade do usuário no servidor é representada por uma instância
javax.security.auth.Subject ou uma instância org.jboss.security.RunAsIdentity. Ambas as classes armazenam um ou mais principais que representam a identidade e uma lista de funções que a identidade possui. No caso do javax.security.auth.Subject, uma lista de credenciais é também armazenada.
Na seção <assembly-descriptor> do descritor de implantação
ejb-jar.xml, você especifica uma ou mais funções que um usuário deve acessar para os diversos métodos EJB. Uma comparação destas listas mostra se o usuário possui uma das funções necessárias para acessar o método EJB.
Exemplo 12.7. Criação do org.jboss.security.RunAsIdentity
No arquivo
ejb-jar.xml, você especifica um elemento <security-identity> com uma função <run-as> definida como o filho do elemento <session>.
Esta declaração significa que a função "Admin" RunAsIdentity deve ser criada.
Para nomear o principal da função Admin, você deverá definir um elemento
<run-as-principal> no arquivo jboss-web.xml.
O elemento
<security-identity> em ambos os arquivos ejb-jar.xml e jboss-web.xml são analisados no período de implantação. O nome da função <run-as> e o nome <run-as-principal> são armazenados na classe org.jboss.metadata.SecurityIdentityMetaData.
Exemplo 12.8. Determinação de funções múltiplas a um RunAsIdentity
Você pode determinar funções ao RunAsIdentity pelo mapeamento de funções aos principais no descritor de implantação
jboss-web.xml do grupo do elemento <assembly-descriptor>.
No Exemplo 12.7, “Criação do org.jboss.security.RunAsIdentity ”, o
<run-as-principal> da "Marca" foi criado. A configuração nesta amostra estende a função "Admin" pela adição da função "Suporte". A nova função contém principais extras, incluindo o principal definido originalmente "John".
O elemento
<security-role> em ambos os arquivos ejb-jar.xml e jboss.xml são analisados no período de implantação. O <role-name> e os dados <principal-name> são armazenados na classe org.jboss.metadata.SecurityIdentityMetaData.
12.1.11. ClientLoginModule
Copiar o linkLink copiado para a área de transferência!
O
ClientLoginModule (org.jboss.security.ClientLoginModule) é uma implantação do LoginModule para uso dos clientes JBoss, com o objetivo de estabelecer a identidade do chamador e credenciais. Basicamente, isto determina o org.jboss.security.SecurityAssociation.principal ao valor do NameCallback preenchido pelo callbackhandler e o org.jboss.security.SecurityAssociation.credential para o valor do PasswordCallback preenchido pelo callbackhandler.
O
ClientLoginModule é o único mecanismo suportado por um cliente para estabelecer o chamador do segmento atual. Ambos os aplicativos do cliente autônomo e os ambientes do servidor (atuando como clientes do JBoss EJB onde o ambiente de segurança não foi configurado para uso do JBossSX) devem usar o ClientLoginModule.
Perceba que este módulo de logon não executa qualquer autenticação. Ele apenas copia a informação de logon fornecida à mesma na camada de invocação do EJB do servidor do JBoss para subsequentes autenticações no servidor. Caso você precise executar a autenticação ao lado do cliente dos usuários, você precisará configurar outro módulo de logon, além do
ClientLoginModule.
As opções do módulo de logon suportadas incluem o seguinte:
- multi-threaded
- O valor que especifica a maneira que os segmentos de logon conectam-se às fontes de armazenamento credencial e principal. Cada segmento de logon possui o próprio armazenamento credencial e principal e cada segmento separado deve executar o próprio logon, quando configurado para verdadeiro. Isto é útil em ambientes onde as identidades do usuário múltiplo são ativas em segmentos separados. A identidade de logon e as credenciais são variáveis aplicáveis a todos os segmentos no VM, quando configurado para falso. A configuração padrão é
false. - password-stacking
- Ativa a autenticação ao lado dos clientes usando outros módulos de logon tais como o
LdapLoginModule. Quando a opçãopassword-stackingfor configurada parauseFirstPass, o módulo primeiramente observa o nome de usuário compartilhado e senha usando ojavax.security.auth.login.nameejavax.security.auth.login.passwordrespectivamente no mapa do estado compartilhado do módulo de logon. Isto permite que um módulo configurado anteriormente à estabelecer um nome e senha de usuário do JBoss válidos. - restore-login-identity
- O valor que especifica se é que o principal e credencial
SecurityAssociationvistos na entrada do métodologin()estão salvos e restaurados tanto quando abortando ou finalizando. Isto é necessário se você alterar as identidades e restaurar a identidade do chamador original. A informação principal e credencial são salvas e restauradas quando anulando ou finalizando, caso configurado paratrue. Caso configurado paraSecurityAssociation, a anulação ou finalização esvaziarão oSecurityAssociation.
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}