Membro do grupo GlassFish JDBC Realm

Eu tenho estado ocupado configurando autenticação, um reino JDBC em particular, no GlassFish 3.1. Eu tenho operado sob a suposição de que:

  • A tabela “Usuário” contém o nome de login (“email_address”) e a senha (“password”)
  • A tabela “Grupo” contém uma lista de nomes de grupos (“nome”)
  • Uma tabela “User_Group” faz o agrupamento de usuários e grupos.

Em nenhum lugar eu era capaz de configurar a tabela “User_Group”, então fiquei me perguntando como o servidor seria capaz de combinar usuários até grupos. Escusado será dizer que não funcionou. Uma inspeção mais atenta sugere, no entanto, que:

  • A tabela “Usuário” contém o nome de login (“email_address”) e a senha (“password”)
  • A tabela “Grupo” contém o nome de login (“email_address”) como chave primária , e uma lista separada por vírgulas de nomes de grupos (“Administrador, Usuário”) em uma única coluna (“grupos”)

Isso está correto e, em caso afirmativo, por que se dar ao trabalho de criar uma tabela “Grupo” separada? Como parece que você pode ter apenas um grouplist por login (“email_address”) não seria tão fácil quanto simplesmente adicionar uma coluna chamada “groups” à tabela “User” e descartar a tabela “Group”?

Obrigado!

Não tenho certeza de qual material você seguiu para configurar o domínio JDBC, mas parece estar incompleto ou incorreto. A seguir, uma descrição da configuração que usei para configurar o território JDBC.


A estrutura do database (como instruções DDL):

A tabela USERS

CREATE TABLE USERS ( USERID VARCHAR(50) NOT NULL, PASSWORD VARCHAR(128) NOT NULL ); --//@UNDO DROP TABLE USERS; 

A tabela GRUPOS

 CREATE TABLE GROUPS ( GROUPID VARCHAR(20) NOT NULL ); --//@UNDO DROP TABLE GROUPS; 

A tabela de associação USERS_GROUPS

 CREATE TABLE USERS_GROUPS ( GROUPID VARCHAR(20) NOT NULL, USERID VARCHAR(50) NOT NULL ); --//@UNDO DROP TABLE USERS_GROUPS; 

O fragment de configuração do GlassFish JDBCRealm de domain.xml :

             

Observe que o atributo group-name-column possui um valor GROUPID , que é mapeado para a coluna GROUPID da tabela de junit USERS_GROUPS e não para a GROUPS tabela de GROUPS . Isso ocorre porque o JDBCRealm emite as seguintes instruções SQL (se você descompilar a class com.sun.enterprise.security.auth.realm.jdbc.JDBCRealm ):

A consulta de senha, com o ID do usuário sendo o parâmetro que é passado do DigestLoginModule:

 SELECT  FROM  WHERE  = ? 

A consulta de grupo, com o ID do usuário sendo passado como o parâmetro:

 SELECT  FROM  WHERE  = ?; 

Quando você considera a estrutura da segunda consulta, é óbvio que a tabela de grupo deve conter o ID do usuário mapeado para um ID de grupo (que leva à duplicação de dados de grupo para usuários mapeados para vários grupos) ou que a Tabela de grupo deve ser a tabela de junit que mapeia usuários para grupos.