Uploaded image for project: 'WildFly Core'
  1. WildFly Core
  2. WFCORE-1886

Adding ldap-realm in Elytron sometimes register capability even if add operation failed

XMLWordPrintable

    • Hide

      1) Start server in debug mode.
      2) Use jdb command line utility from JDK for slowing command execution:

      jdb -attach 8787
      

      and add breakpoint:

      stop in org.wildfly.extension.elytron.LdapRealmDefinition$RealmAddHandler.configureIdentityMapping(org.jboss.as.controller.OperationContext,org.jboss.dmr.ModelNode,org.wildfly.security.auth.realm.ldap.LdapSecurityRealmBuilder)
      

      3) Open CLI and run following commands.
      Firstly add dir-context, because it is needed for adding ldap-realm:

      /subsystem=elytron/dir-context=dir:add(url=localhost)
      

      Then add ldap-realm with missing required attribute rdn-identifier:

      /subsystem=elytron/ldap-realm=ldap:add(dir-context=dir,identity-mapping={user-password-mapper={verifiable=true,writable=true}})
      

      Breakpoint in jdb is hit, wait 5second and then run command cont in jdb. Output in CLI is:

      {
          "outcome" => "failed",
          "failure-description" => "WFLYCTL0155: rdn-identifier may not be null",
          "rolled-back" => true
      }
      

      4) Fix CLI command and execute it:

      /subsystem=elytron/ldap-realm=ldap:add(dir-context=dir,identity-mapping={rdn-identifier=1,user-password-mapper={verifiable=true,writable=true}})
      

      It fail with description says that capability is already registered:

      {
          "outcome" => "failed",
          "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.security.security-realm.ldap' is already registered in context 'global'.",
          "rolled-back" => true
      }
      

      5) Reload server and run fixed command again, it will finish successfully:

      reload
      /subsystem=elytron/ldap-realm=ldap:add(dir-context=dir,identity-mapping={rdn-identifier=1,user-password-mapper={verifiable=true,writable=true}})
      {"outcome" => "success"}
      
      Show
      1) Start server in debug mode. 2) Use jdb command line utility from JDK for slowing command execution: jdb -attach 8787 and add breakpoint: stop in org.wildfly.extension.elytron.LdapRealmDefinition$RealmAddHandler.configureIdentityMapping(org.jboss.as.controller.OperationContext,org.jboss.dmr.ModelNode,org.wildfly.security.auth.realm.ldap.LdapSecurityRealmBuilder) 3) Open CLI and run following commands. Firstly add dir-context, because it is needed for adding ldap-realm: /subsystem=elytron/dir-context=dir:add(url=localhost) Then add ldap-realm with missing required attribute rdn-identifier: /subsystem=elytron/ldap-realm=ldap:add(dir-context=dir,identity-mapping={user-password-mapper={verifiable= true ,writable= true }}) Breakpoint in jdb is hit, wait 5second and then run command cont in jdb . Output in CLI is: { "outcome" => "failed" , "failure-description" => "WFLYCTL0155: rdn-identifier may not be null " , "rolled-back" => true } 4) Fix CLI command and execute it: /subsystem=elytron/ldap-realm=ldap:add(dir-context=dir,identity-mapping={rdn-identifier=1,user-password-mapper={verifiable= true ,writable= true }}) It fail with description says that capability is already registered: { "outcome" => "failed" , "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.security.security-realm.ldap' is already registered in context 'global' ." , "rolled-back" => true } 5) Reload server and run fixed command again, it will finish successfully: reload /subsystem=elytron/ldap-realm=ldap:add(dir-context=dir,identity-mapping={rdn-identifier=1,user-password-mapper={verifiable= true ,writable= true }}) { "outcome" => "success" }

      In case when adding Elytron ldap-realm capability through CLI takes some time (e.g. 5 seconds) then this capability is registered in context even if command failed (e.g. because some required attribute is missing). Then when command is fixed it cannot be added since capability was already registered. Server has to be reloaded to unregister this non-exist capability. See 'Steps to Reproduce' for more detail.

      I am able to simulate this behavior with ldap-realm from Elytron. However I am not sure whether this issue can be related to whole Elytron subsystem or whole Domain Model.

      Exception in server log:

      ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("add") failed - address: ([
          ("subsystem" => "elytron"),
          ("ldap-realm" => "ldap")
      ]): java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.security.security-realm.ldap' is already registered in context 'global'.
      	at org.jboss.as.controller.CapabilityRegistry.registerCapability(CapabilityRegistry.java:158)
      	at org.jboss.as.controller.OperationContextImpl.registerCapability(OperationContextImpl.java:1449)
      	at org.jboss.as.controller.OperationContextImpl.registerCapability(OperationContextImpl.java:1441)
      	at org.jboss.as.controller.AbstractAddStepHandler.recordCapabilitiesAndRequirements(AbstractAddStepHandler.java:274)
      	at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:146)
      	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
      	at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
      	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
      	at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
      	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
      	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
      	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
      	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
      	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
      	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
      	at java.security.AccessController.doPrivileged(Native Method)
      	at javax.security.auth.Subject.doAs(Subject.java:422)
      	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
      	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
      	at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
      	at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
      	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
      	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
      	at java.lang.Thread.run(Thread.java:745)
      	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
      

              bstansbe@redhat.com Brian Stansberry
              olukas Ondrej Lukas (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated:
                Resolved: