4 Replies Latest reply on Dec 19, 2018 5:31 AM by Martin Choma

    EE 8:  Issues with Database Identity Store Definition

    Tim Baronetti Newbie

      I am trying to get EE 8 database identity store security working on Wildfly 13 (EE8 preview mode is switched on). I am using the example java code from here: tutorial-examples/security/security-api/built-in-db-identity-store at master · javaee/tutorial-examples · GitHub  

      (I have also modifed the pom.xml to reference the necessary Wildfly plugins/dependencies).

       

      I now have most of this working but I have a couple of issues/queries. So far I have done the following:

       

      1. Successfully configured Elytron security on the Wildfly server with the relevant security/domain/realm realm and included the necessary principal query select statements, http authentication factory, etc..

      2. Deployed the application.

       

      On running the application in a browser:

       

      1. The database is successfully populated with usernames, hashed passwords and user roles.

      2. Basic authentication UI appears. When entering username and password, authentication fails. However, when enter the hashed password string into the UI authentication succeeds and the web page is correctly displayed!

       

      I have a number of questions:

       

      1. The following code snippet is from ApplicationConfig.java, which is Application Scoped. @DatabaseIdentityStoreDefinition seems to attempt to address 2 purposes -

       

           a) to define the database and SQL query details needed to perform authentication / role authorization checks and

           b) to provide hashing algorithm parameters to the Pbkdf2PasswordHash class.

       

      // Database Definition for built-in DatabaseIdentityStore

      @DatabaseIdentityStoreDefinition(

              dataSourceLookup = "java:/app_identity_store",   

              callerQuery = "#{'SELECT password from APP_USER where username = ?'}",

              groupsQuery = "SELECT R.role_name from APP_ROLE AS R, USER_ROLE AS UR, APP_USER AS U WHERE U.username = ? AND UR.role_id = R.id AND UR.user_id = U.id",

              hashAlgorithm = Pbkdf2PasswordHash.class,

              priorityExpression = "#{100}",

              hashAlgorithmParameters = {

                  "Pbkdf2PasswordHash.Iterations=3072",

                  "${applicationConfig.dyna}"

              }

      )

       

      However, the actual behaviour is a bit confusing.

       

      a) When DatabaseSetup runs on startup (ie on deployment or server start up), it seems to ignore the first 3 lines of @DatabaseIdentityStoreDefinition because the database is still successfully populated even when these lines are removed. Therefore I conclude that the application must be referencing the principal query as configured in standalone-full.xml on the Wildfly server itself. If that is the case, what purpose is served by including principal query parameters in  ApplicationConfig.java. Why do we need to define this twice (once on Wildfly and once in the application) ? I thought (perhaps mistakenly) that @DatabaseIdentityStoreDefinition would allow us to configure these queries externally to the application server without needing to update standalone-full.xml ?

       

      b) Password authentication behaviour is weird. It is correctly stored as a hash in the database but I want to enter the unhashed clear password on the application login UI and have the security module automatically hash  and then compare it against the hashed password in the database to authenticate the user. Surely that is the whole job of the security api to do this? I must be misunderstanding this. How can a make it work correctly?

       

      Further questions:

       

      1. Is there some way to define the security domain without a jboss-web.xml?  I tried using @SecurityDomain("jdbcRealm") in the servlet but it apparently  ignores this annotation. Without defining the security domain in jboss-web.xml, the servlet responds with "Forbidden".

      2. Since ApplicationConfig is not injected into any other class, or explicitly referenced from other java classes, how is it actually ever instantiated?