Glassfish 3 security – Autenticação baseada em formulário usando um JDBC Realm

Eu quero entender segurança baseada em formulário e realms JDBC com glassfishV3, então eu decidi criar um pequeno aplicativo que apenas permite entrar e sair, eu segui as instruções deste livro para fazê-lo.

Eu entendo como a coisa funciona, mas algo está errado e eu não consigo fazer funcionar corretamente.

O que eu fiz primeiro foi criar um pequeno database com annotations JPA:

@Entity @Table(name="USERS") public class User implements Serializable { private static final long serialVersionUID = -1244856316278032177L; @Id @GeneratedValue @Column(nullable = false) private Long id; @Column(nullable = false) private String email; @Column(nullable = false) private String password; @OneToMany(mappedBy = "user") private List groups; //GET & SET METHODS... } 

Aqui a outra tabela que detém as funções para cada usuário

 @Entity @Table(name="GROUPS") public class Group implements Serializable { private static final long serialVersionUID = -7274308564659753174L; @Id @GeneratedValue @Column(nullable = false) private Long id; @Column(nullable = false) private String groupName; @ManyToOne @JoinColumn(name = "USERS_ID", nullable = false) private User user; //GET & SET METHODS... } 

Quando o database estava pronto, adicionei alguns dados manualmente

insira a descrição da imagem aqui

O próximo passo foi configurar um domínio de segurança.

insira a descrição da imagem aqui

Em seguida, adicionei a configuração de segurança ao meu arquivo web.xml

   CHAPTER x 12 Container Managed Authentication and Authorization  index.xhtml   Faces Servlet javax.faces.webapp.FacesServlet 1   Faces Servlet *.xhtml    VISITOR PERMISIONS /index.xhtml /visitorpanel.xhtml GET POST   visitors users administrators     USERS PERMISIONS /userpanel.xhtml /index.xhtml /visitorpanel.xhtml GET POST   users administrators     ADMIN PERMISIONS /adminpanel.xhtml /userpanel.xhtml /index.xhtml /visitorpanel.xhtml GET POST   administrators    FORM DBRealm  /index.xhtml /error.xhtml    visitors   users   administrators   

Meus objectives aqui foram:

  • os administradores podem ver todas as páginas

  • os visitantes podem ver apenas index.xhtml e visitorpanel.xhtml

  • os usuários podem ver index.xhtml, visitorpanel.xhtml e userpanel.xhtml

Eu acho que a configuração está correta.

Finalmente, o último passo foi criar o formulário de login na página index.xhtml:

    

O programa constrói bem, mas eu tenho os seguintes problemas:

1- Quando tento logar como usuário ou como administrador (os visitantes não precisam fazer o login), sou redirecionado para a página error.xhtml e no console vejo uma exceção:

SEVERE: SEC1112: Não é possível validar o usuário [admin@gmail.com] para o domínio JDBC. AVISO: Falha no login da Web: Falha no logon: javax.security.auth.login.LoginException: exceção de segurança Aviso: PWC4011: não é possível definir a codificação de caracteres de solicitação como UTF-8 no contexto / CHAPTER_12_x_Container_Managed_Authentication_and_Authorization, porque os parâmetros de solicitação já foram lidos ou ServletRequest .getReader () já foi chamado

2- Quando tento navegar para algumas das páginas através do URL, nada acontece. Eu acho que está tudo bem, mas quando eu tento visitar visitorpanel.xhtml, deve deixar, porque não há necessidade de estar logado para vê-lo. Preciso remover essa página da configuração de segurança se desejar que todo o corpo a veja?

3- Também estou curioso porque eu não posso usar a tag h: form em vez de apenas form, quando eu implementar o login?

Eu realmente aprecio alguma ajuda, tenho estado algumas horas lendo os primeiros capítulos do livro e tentando implementar, meu próprio exemplo, mas eu fiquei preso. Eu acho que estou perto da solução.

Atualizar

Eu mudei o principal padrão para ser o nome de usuário dos visitantes. Mas ainda não funciona

insira a descrição da imagem aqui

E eu também adicionei mais algumas opções à minha configuração do Realm

insira a descrição da imagem aqui

Mas quando tento logar ainda vejo uma exceção que diz:

SEVERE: SEC1112: Não é possível validar o usuário [admin@gmail.com] para o domínio JDBC. AVISO: Falha no login da Web: Falha no logon: javax.security.auth.login.LoginException: exceção de segurança Aviso: PWC4011: não é possível definir a codificação de caracteres de solicitação como UTF-8 no contexto / CHAPTER_12_x_Container_Managed_Authentication_and_Authorization, porque os parâmetros de solicitação já foram lidos ou ServletRequest .getReader () já foi chamado

Eu ainda não sei o que está faltando.

-Pode ser que o nome da tabela não seja maiúsculo?

-Pode ser que os nomes das colunas não sejam maiúsculos?

-Pode ser que as tabelas sejam criadas erradas?

-Pode ser que eu não posso usar PASSWORD como um nome de coluna, porque faz algum tipo de conflito?

Eu realmente não entendo porque essa exceção. Fiz o ping no database do painel de administração e tudo parece estar correto.

Alguém pode me ajudar a descobrir isso?

Atualização 2

Eu mudei a opção de registro ‘javax.enterprise.system.core.security’ para o nível FINE, para ter mais informações quando exceções ocorrerem, este foi o resultado quando eu tentei logar:

FINE: Intercept Entrada: interceptar: SOAP defaultServerID: null defaultClientID: nulo FINE: Entrada de ID: class do módulo: com.sun.xml.wss.provider.ClientSecurityAuthModule id: XWS_ClientProvider type: política de solicitação do cliente: javax.security.auth.message. Política de resposta de MessagePolicy @ e95a72: javax.security.auth.message.MessagePolicy@310a6d options: {signature.key.alias = s1as, debug = false, dynamic.username.password = false, encryption.key.alias = s1as} FINE: ID Entry: módulo class: com.sun.xml.wss.provider.ClientSecurityAuthModule id: tipo ClientProvider: política de solicitação do cliente: javax.security.auth.message.MessagePolicy@1829770 diretiva de resposta: javax.security.auth.message.MessagePolicy @ a4461e options: {signature.key.alias = s1as, debug = false, dynamic.username.password = false, encryption.key.alias = s1as, security.config = C: \ jeeAplicationServer \ glassfishv3 \ glassfish \ domains \ domain1 / config /wss-server-config-1.0.xml} FINE: Entrada de ID: class do módulo: com.sun.xml.wss.provider.ServerSecurityAuthModule id: XWS_ServerPro tipo de vider: política de solicitação do servidor: javax.security.auth.message.MessagePolicy@f79c86 política de resposta: javax.security.auth.message.MessagePolicy@454bf7 options: {signature.key.alias = s1as, debug = false, encryption.key .alias = s1as} FINE: input ID: módulo class: com.sun.xml.wss.provider.ServerSecurityAuthModule id: tipo ServerProvider: política de solicitação do servidor: javax.security.auth.message.MessagePolicy@17e85e4 política de resposta: javax.security .auth.message.MessagePolicy @ 1887906 opções: {signature.key.alias = s1as, debug = false, encryption.key.alias = s1as, security.config = C: \ jeeAplicationServer \ glassfishv3 \ glassfish \ domains \ domain1 / config / wss-server-config-1.0.xml} FINE: [Segurança da Web] Configuração ID do Contexto da Política: old = null ctxID = CAPTER_x_12_Container_Managed_Authentication_and_Authorization / CHAPTER_x_12_Container_Managed_Authentication_and_Authorization FINE: [Segurança da Web] hasUserDataPermission perm: (javax.security.jacc.WebUserDataPermission / j_security_check POST) FINE: [Web-Security] hasUserDat aPermission isGranted: true FINE: Efetuando login do usuário [admin@gmail.com] no domínio: DBRealm usando o módulo JAAS: jdbcRealm FINE: Módulo de login inicializado: class com.sun.enterprise.security.auth.login.JDBCLoginModule SEVERE: SEC1112: Cannot valide o usuário [admin@gmail.com] para o domínio JDBC. FINE: Não é possível validar o usuário javax.security.auth.login.LoginException: Não é possível conectar-se à origem de dados jdbc / security para o usuário usuário do database. em com.sun.enterprise.security.auth.realm.jdbc.JDBCRealm.getConnection (JDBCRealm.java:550) em com.sun.enterprise.security.auth.realm.jdbc.JDBCRealm.isUserValid (JDBCRealm.java:393) em com.sun.enterprise.security.auth.realm.jdbc.JDBCRealm.authenticate (JDBCRealm.java:311) em com.sun.enterprise.security.auth.login.JDBCLoginModule.authenticate (JDBCLoginModule.java:72) at com .sun.enterprise.security.auth.login.PasswordLoginModule.authenticateUser (PasswordLoginModule.java:90) em com.sun.appserv.security.AppservPasswordLoginModule.login (AppservPasswordLoginModule.java:141) em sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Método) em sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) em sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) em java.lang.reflect.Method.invoke (Method.java:597) em javax.security.auth.login.LoginContext.invoke (LoginContext.java:769) em javax.security.auth.login.LoginContext.access $ 000 (LoginContext.java: 186) em javax.security.auth.login.LoginContext $ 4.run (LoginContext.java:683) em java.security.AccessController.doPrivileged (Native Method) em javax.security.auth.login.LoginContext.invokePriv (LoginContext.java : 680) em javax.security.auth.login.LoginContext.login (LoginContext.java:579) em com.sun.enterprise.security.auth.login.LoginContextDriver.doPasswordLogin (LoginContextDriver.java:341) em com.sun. enterprise.security.auth.login.LoginContextDriver.login (LoginContextDriver.java:199) em com.sun.enterprise.security.auth.login.LoginContextDriver.login (LoginContextDriver.java:152) em com.sun.web.security. RealmAdapter.authenticate (RealmAdapter.java:479) em com.sun.web.security.RealmAdapter.authenticate (RealmAdapter.java:418) em org.apache.catalina.authenticator.FormAuthenticator.authenticate (FormAuthenticator.java:264) em org .apache.catalina.authenticator.AuthenticatorBase.processSecurityCheck (AuthenticatorBase.java:1015) em org.apache.catalina.authenticator.AuthenticatorBase.invoke (Authenti catorBase.java:614) em org.apache.catalina.core.StandardPipeline.invoke (StandardPipeline.java:615) em com.sun.enterprise.web.WebPipeline.invoke (WebPipeline.java:97) em com.sun.enterprise .web.PESessionLockingStandardPipeline.invoke (PESessionLockingStandardPipeline.java:85) em org.apache.catalina.core.StandardHostValve.invoke (StandardHostValve.java:185) em org.apache.catalina.connector.CoyoteAdapter.doService (CoyoteAdapter.java:325 ) em org.apache.catalina.connector.CoyoteAdapter.service (CoyoteAdapter.java:226) em com.sun.enterprise.v3.services.impl.ContainerMapper.service (ContainerMapper.java:165) em com.sun.grizzly. http.ProcessorTask.invokeAdapter (ProcessorTask.java:791) em com.sun.grizzly.http.ProcessorTask.doProcess (ProcessorTask.java:693) em com.sun.grizzly.http.ProcessorTask.process (ProcessorTask.java:954) em com.sun.grizzly.http.DefaultProtocolFilter.execute (DefaultProtocolFilter.java:170) em com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter (DefaultProtocolChain.java:135) em com.sun.grizzly.DefaultProtocolChain.execute (DefaultProtocolChain.java:102) em com.sun.grizzly.DefaultProtocolChain.execute (DefaultProtocolChain.java:88) em com.sun.grizzly.http.HttpProtocolChain.execute (HttpProtocolChain.java : 76) em com.sun.grizzly.ProtocolChainContextTask.doCall (ProtocolChainContextTask.java:53) em com.sun.grizzly.SelectionKeyContextTask.call (SelectionKeyContextTask.java:57) em com.sun.grizzly.ContextTask.run (ContextTask. java: 69) em com.sun.grizzly.util.AbstractThreadPool $ Worker.doWork (AbstractThreadPool.java:330) em com.sun.grizzly.util.AbstractThreadPool $ Worker.run (AbstractThreadPool.java:309) em java.lang .Thread.run (Thread.java:662) Causado por: javax.naming.NamingException: Lookup falhou para ‘jdbc / security’ em SerialContext [A exceção raiz é javax.naming.NameNotFoundException: segurança não encontrada] em com.sun.enterprise .naming.impl.SerialContext.lookup (SerialContext.java:442) em javax.naming.InitialContext.lookup (InitialContext.java:392) em javax.naming.InitialCo ntext.lookup (InitialContext.java:392) em com.sun.enterprise.connectors.service.ConnectorResourceAdminServiceImpl.lookup (ConnectorResourceAdminServiceImpl.java:203) em com.sun.enterprise.connectors.ConnectorRuntime.lookupNonTxResource (ConnectorRuntime.java:440) em com.sun.enterprise.security.auth.realm.jdbc.JDBCRealm.getConnection (JDBCRealm.java:538) … 44 mais Causado de: javax.naming.NameNotFoundException: security not found at com.sun.enterprise.naming .impl.TransientContext.doLookup (TransientContext.java:197) em com.sun.enterprise.naming.impl.TransientContext.lookup (TransientContext.java:168) em com.sun.enterprise.naming.impl.TransientContext.lookup (TransientContext .java: 172) em com.sun.enterprise.naming.impl.SerialContextProviderImpl.lookup (SerialContextProviderImpl.java:58) em com.sun.enterprise.naming.impl.LocalSerialContextProviderImpl.lookup (LocalSerialContextProviderImpl.java:101) em com. sun.enterprise.naming.impl.SerialContext.lookup (SerialContext.java:430) … 49 mais

FINE: Autenticação JAAS anulada. ADVERTÊNCIA: Falha ao efetuar login na Web: Falha no login: javax.security.auth.login.LoginException: Exceção de segurança FINE: A identificação de contexto da política [Web-Security] era: CHAPTER_x_12_Container_Managed_Authentication_and_Authorization / CHAPTER_x_12_Container_Managed_Authentication_and_Authorization FINE: [Segurança da Web] hasUserDataPermission perm: (javax.security .jacc.WebUserDataPermission /error.xhtml GET) FINE: [Segurança da Web] hasUserDataPermission isGranted: true

Atualização 3

Talvez haja algo errado com o pool de conexão. É assim que meu pool de conexões se parece:

insira a descrição da imagem aqui

insira a descrição da imagem aqui

insira a descrição da imagem aqui

Eu não tenho muitas propriedades, talvez algo esteja faltando?

Também agora eu criei um recurso JDBC, que se parece com isso:

insira a descrição da imagem aqui

(O nome da JNDI no Reino, foi alterado para jdbc / studydb)

Meu persistence.xml se parece com isso:

    jdbc/studydb entities.User entities.Group   

Acho que fiz algum progresso, agora a exceção que vejo é:

 > SEVERE: jdbcrealm.invaliduserreason > FINE: Cannot validate user > java.sql.SQLSyntaxErrorException: Schema 'ADMIN' does not exist > at org.apache.derby.client.am.SQLExceptionFactory40.getSQLException(Unknown > Source) > .... > > Caused by: org.apache.derby.client.am.SqlException: Schema 'ADMIN' does not exist > at org.apache.derby.client.am.Statement.completeSqlca(Unknown Source) > ... > FINE: JAAS authentication aborted. > WARNING: Web login failed: Login failed: javax.security.auth.login.LoginException: Security Exception > FINE: [Web-Security] Policy Context ID was: CHAPTER_x_12_Container_Managed_Authentication_and_Authorization/CHAPTER_x_12_Container_Managed_Authentication_and_Authorization > FINE: [Web-Security] hasUserDataPermission perm: (javax.security.jacc.WebUserDataPermission /error.xhtml GET) > FINE: [Web-Security] hasUserDataPermission isGranted: true > WARNING: PWC4011: Unable to set request character encoding to UTF-8 from context > /CHAPTER_12_x_Container_Managed_Authentication_and_Authorization, > because request parameters have already been read, or > ServletRequest.getReader() has already been called 

Atualização 4

Eu mudei o database, foi organizado erroneamente, então eu fiz algumas mudanças nas minhas entidades:

 @Entity @Table(name="USERS", schema="ADMIN") public class User implements Serializable { private static final long serialVersionUID = -1244856316278032177L; @Id @Column(nullable = false) private String userid; @Column(nullable = false) private String password; @ManyToOne @JoinTable(name="USER_GROUP",schema="ADMIN", joinColumns = @JoinColumn(name="userid", referencedColumnName="userid"), inverseJoinColumns=@JoinColumn(name="groupid", referencedColumnName= "groupid") ) private Group group; //GET & SET METHODS 

@Entity @Table (name = “GROUPS”, schema = “ADMIN”) public class Grupo implementa Serializable {

 private static final long serialVersionUID = -7274308564659753174L; @Id @Column(nullable = false) private String groupid; @OneToMany(mappedBy="group") private Set users; 

// GET & SET METHODS

Então eu também tive que editar o DBRealm, agora parece com isso:

insira a descrição da imagem aqui

Mas quando eu login eu recebo novamente uma exceção:

 FINE: [Web-Security] Policy Context ID was: CHAPTER_x_12_Container_Managed_Authentication_and_Authorization/CHAPTER_x_12_Container_Managed_Authentication_and_Authorization FINE: [Web-Security] hasUserDataPermission perm: (javax.security.jacc.WebUserDataPermission /j_security_check POST) FINE: [Web-Security] hasUserDataPermission isGranted: true FINE: Logging in user [user@gmail.com] into realm: DBRealm using JAAS module: jdbcRealm FINE: Login module initialized: class com.sun.enterprise.security.auth.login.JDBCLoginModule SEVERE: SEC1111: Cannot load group for JDBC realm user [user@gmail.com]. FINE: Cannot load group java.sql.SQLSyntaxErrorException: Column 'USERID' is either not in any table in the FROM list or appears within a join specification and is outside the scope of the join specification or appears in a HAVING clause and is not in the GROUP BY list. If this is a CREATE or ALTER TABLE statement then 'USERID' is not a column in the target table. .... .... Caused by: org.apache.derby.client.am.SqlException: Column 'USERID' is either not in any table in the FROM list or appears within a join specification and is outside the scope of the join specification or appears in a HAVING clause and is not in the GROUP BY list. If this is a CREATE or ALTER TABLE statement then 'USERID' is not a column in the target table. at org.apache.derby.client.am.Statement.completeSqlca(Unknown Source) .... .... FINE: JAAS login complete. FINE: JAAS authentication committed. FINE: Password login succeeded for : user@gmail.com FINE: permission check done to set SecurityContext FINE: Set security context as user: user@gmail.com FINE: [Web-Security] Policy Context ID was: CHAPTER_x_12_Container_Managed_Authentication_and_Authorization/CHAPTER_x_12_Container_Managed_Authentication_and_Authorization FINE: [Web-Security] hasUserDataPermission perm: (javax.security.jacc.WebUserDataPermission GET) FINE: [Web-Security] hasUserDataPermission isGranted: true FINE: permission check done to set SecurityContext FINE: SecurityContext: setCurrentSecurityContext method called FINE: [Web-Security] Policy Context ID was: CHAPTER_x_12_Container_Managed_Authentication_and_Authorization/CHAPTER_x_12_Container_Managed_Authentication_and_Authorization FINE: [Web-Security] hasUserDataPermission perm: (javax.security.jacc.WebUserDataPermission /adminpanel.xhtml GET) FINE: [Web-Security] hasUserDataPermission isGranted: true FINE: [Web-Security] Policy Context ID was: CHAPTER_x_12_Container_Managed_Authentication_and_Authorization/CHAPTER_x_12_Container_Managed_Authentication_and_Authorization FINE: [Web-Security] Generating a protection domain for Permission check. FINE: [Web-Security] Checking with Principal : user@gmail.com FINE: [Web-Security] Checking with Principal : visitors FINE: [Web-Security] Checking with Principal : users FINE: [Web-Security] Checking with Principal : administrators FINE: [Web-Security] Codesource with Web URL: file:/CHAPTER_x_12_Container_Managed_Authentication_and_Authorization/CHAPTER_x_12_Container_Managed_Authentication_and_Authorization FINE: [Web-Security] Checking Web Permission with Principals : user@gmail.com, visitors, users, administrators FINE: [Web-Security] Web Permission = (javax.security.jacc.WebResourcePermission /adminpanel.xhtml GET) FINE: [Web-Security] hasResource isGranted: true FINE: [Web-Security] hasResource perm: (javax.security.jacc.WebResourcePermission /adminpanel.xhtml GET) FINE: SecurityContext: setCurrentSecurityContext method called WARNING: Resource not found: com/sun/enterprise/v3/admin/adapter/theme/com/sun/webui/jsf/suntheme/images/masthead/masthead_button_over.gif 

Existem alguns bits ausentes em sua configuração:

  • A senha é armazenada em texto não criptografado no database. Isso é mais provável incorreto. O Glassfish 3.1 usa o algoritmo SHA-256 por padrão, de modo que o JDBC Realm falharia na autenticação de usuários, já que o valor armazenado no database não corresponderia ao resumo criado pelo Reino. Você precisará especificar um algoritmo de resumo explícito na configuração da região ou confiar no padrão. Além disso, você precisará garantir que seu aplicativo crie os resumos quando um novo usuário for criado ou quando sua senha for modificada. Se você quiser armazenar a senha em texto simples, você deve especificar o valor de “none” para o algoritmo de resumo.
  • Especificar o algoritmo de resumo sozinho é insuficiente. Você precisará especificar a codificação na qual o resumo é armazenado (uma vez que um resumo é simplesmente uma sequência de bytes e pode não ser armazenado como uma sequência ASCII simples). O Glassfish suporta codificação Hex e Base64 e usa a codificação Hex por padrão. Seu aplicativo deve, portanto, aplicar a mesma codificação configurada no território, antes de armazenar o resumo de senha. Observe que, quando você especifica um algoritmo de resumo de “nenhum” para armazenar as senhas em texto simples, não é necessário codificar a senha armazenada (e, da mesma forma, também não é necessário especificar uma codificação); pelo menos esta foi minha observação da leitura das fonts Glassfish.
  • Além disso, o mapeamento do grupo de usuários parece ser de 1: 1 no momento. Você pode querer usar uma tabela de junit separada para permitir mapeamentos 1: N entre grupos e usuários.
  • Você também precisará garantir que a opção “principal padrão para o mapeamento de funções” esteja ativada. Sem essa opção, você precisará mapear manualmente as funções no web.xml para usuários e grupos em seu território .

No tópico de usar o form vez de h:form , o motivo subjacente é que o tempo de execução do JSF não permitiria que você especificasse o atributo de action da tag h:form . Esse valor é definido pelo tempo de execução JSF, ao codificar a resposta e, portanto, você não poderá especificar o valor de j_security_check ao usar a tag h:form . A documentação afirma isso bem explicitamente :

O valor do atributo “action” deve ser o resultado da passagem do identificador de exibição da exibição atual para o método getActionURL() do ViewHandler para esse aplicativo e, em seguida, passar essa String para o método encodeActionURL() no ExternalContext .

Atualizar

Com base no rastreamento de pilha postada, posso inferir que a origem de dados JNDI (especificada no campo JNDI) a ser usada pelo Reino, não está disponível no domínio Glassfish. Um dos pré-requisitos para o JDBC Realm é ter uma origem de dados JNDI registrada na configuração do domínio Glassfish, cujo pool de conexão é usado para se conectar ao database subjacente.

A seguir está um trecho do meu arquivo de configuração do domínio Glassfish ( domain.xml ) em que um pool de conexão (GalleriaPool) é usado por um JNDI DataSource (jdbc / galleriaDS), que é eventualmente usado pelo JDBC Realm (GalleriaRealm):

   ...                   ...    ...   ...              ...   ...  ...  

Atualização 2 – Obtendo as instruções SQL executadas pelo JDBC Realm contra o Derby

Parece que a estrutura da consulta SQL não corresponde ao modelo de database que você preparou. Você poderia dar uma olhada nas instruções SQL executadas pelo domínio JDBC na instância do Derby através da propriedade do sistema derby.language.logStatementText . Essa propriedade pode ser configurada como true como um valor estático no arquivo derby.properties e terá efeito quando você reiniciar a instância do Derby. O arquivo derby.properties precisa ter a seguinte input:

 derby.language.logStatementText=true 

e esse arquivo deve ser colocado no diretório de trabalho atual da instância do Derby. O diretório de trabalho atual é geralmente o diretório que contém os bancos de dados Derby e pode ser explicitamente especificado usando o argumento da JVM derby.system.home , durante a boot do Derby:

 -Dderby.system.home=C:\derby 

Todas as instruções SQL executadas pelo Derby, agora serão registradas no arquivo derby.log .

Com base nas informações fornecidas, tenho a impressão de que há uma tabela separada chamada GROUPS que é usada para armazenar as informações do grupo, e isso é diferente da tabela de associação – USER_GROUP . Nesse cenário, seu território deve ser configurado para ter a tabela Group como USER_GROUP e não GROUP ; Você pode confirmar isso consultando as consultas SQL emitidas pelo domínio JDBC.

Para esclarecer o ponto acima, o campo Grupo na configuração do território JDBC não é usado para especificar a tabela que armazena as informações do grupo. Em vez disso, ele é usado para especificar a tabela que armazena os mapeamentos de usuário do grupo. Em um mapeamento 1: 1, a tabela Group pode armazenar essas informações, mas em um cenário 1: M ou tipicamente em M: M, você teria uma tabela separada que contém o mapeamento. A consulta SQL emitida pela região JDBC usa a tabela de mapeamento e não a tabela de grupos real (se forem diferentes) para determinar os grupos aos quais um usuário pertence.

Além da resposta do Vineet, também notei que a opção Security Manager não está marcada na aba Security do GlassFish, essa opção deve estar habilitada para poder usar o Security em seu Realm.

Outra coisa, se você estiver usando um nome JNBC JDBC, não precisará fornecer um nome de usuário / senha para o domínio JDBC.

Eu já fiz isso no Sailfin (baseado no Glassfish 2).

Primeiro, não vejo nenhum arquivo sun-web.xml que mapeie as funções definidas em seu arquivo web.xml para os grupos definidos no database.

Segundo, de acordo com este tutorial: http://codepimpsdotorg.blogspot.com/2007/12/glassfish-jdbc-realm-authentication.html você deve especificar um algoritmo de resumo (“nenhum” não é uma opção, não tenho certeza se ele permanece o mesmo em Glassfish 3).

Terceiro, as tabelas e colunas precisam estar em uma ordem específica, estamos usando a seguinte estrutura:

 @Entity @Table(name = "AuthenticationUser") public class UserEntity implements Serializable, Identifiable { private static final long serialVersionUID = -1213555368237839900L; @Id @Column(name = "name", length = 20) private String itsName; @Column(name = "password", length = 1024) private String itsPassword; @ManyToOne(fetch = FetchType.LAZY) @JoinColumn(name = "groupName", referencedColumnName = "name") private GroupEntity itsGroupEntity; ... 

E

 @Entity @Table(name = "AuthenticationGroup") public class GroupEntity implements Serializable, Identifiable { private static final long serialVersionUID = -1213554368237839900L; private static final String USER_GROUP_COLUMN = "itsGroupEntity"; @Id @Column(name = "name", length = 20) private String itsName; @OneToMany(cascade = CascadeType.ALL, fetch = FetchType.LAZY, mappedBy=USER_GROUP_COLUMN) private List itsUsers; ... 

And to define the realm:

 user-table=AuthenticationUser user-name-column=name password-column=password group-table=AuthenticationUser group-name-column=groupName 

IMPORTANT: The user name and group name are belonging to the same table! so the table AuthenticationGroup is only for our internal use, but is not used by Glassfish.

Eu tive o mesmo problema.

I solved this problem by renaming the password to(User_password) and the userName (User_name) fields in the table (anything other than username and password will do), somehow using “userName” and “password” causes some conflict while performing authentication using Realms.

Also put Digest Algorithm: = none in case you are storing the password as plain text.

In the Security menu, Enable the Default Principal to Role Mapping.

Espero que isto ajude,