Uploaded image for project: 'OpenAM'
  1. OpenAM
  2. OPENAM-12347

AmPlugin Custom Authentication Module cannot be uninstalled or reregistered

    Details

    • Type: Bug
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 5.5.1, 6.5.2, 6.0.0.7
    • Fix Version/s: None
    • Component/s: authentication, samples
    • Labels:
      None
    • Support Ticket IDs:

      Description

      Bug description

      The whole documentation mentions never to use ssoadm to register the custom authentication module and uses the AMPlugin framework to register the new authentication module. However there are a few issues that is incomplete in this

      a) After the custom module is installed using the onInstall (as in the samples), the module cannot be uninstalled. There is no explicit lifecyle to clean this up. Although the JAR can be removed, there remains residual in the LDAP registry

      b) Due to (a), even if the whole custom auth module is removed and many restart done and if a old plugin is replaces, there will be no changes made as the old registry values exist. The old registry can be removed with ssodm delete-svcs BUT this is of no helps. Doing so makes matter worst and the custom auth module will never appear in the selection

      c) The issue inn (b) is cause by the amPluginService registry holding to registry. So this is also indicating we have no way to remove this to start afresh.

      d) So for (b) and (c), one may think that maybe we use AmPlugin method upgrade(String fromVersion) to do the update of the service registry. This is itself no good as there's lack of API to do this The lacking portion
      i) No error handling in upgrade (what if we throw Exception) and it affect other
      ii) We cannot install the same service twice (like using the method used in onInstall()) so doing so seems like we need some internal API to cleanup things.
      [(d) is probably and RFE but just to indicate this is not easy to workaround this like that]

      Impact
      A initial erroneous Sample Auth module may cause very hard to reason to correct things as the configuration will persists until ssoadm is used to delete things. However the PluginRegistry entry is still there (this may prevent later AMPlugin to run even if the custom auth service is gone).

      How to reproduce the issue

      1. Use the custom authentication sample. But before deploy say remove the resourceName from attributes iPlanetAMAuthSampleAuthService. This is to generated a broken sample auth
      2. Deploy this and restart and see adding this custom sample auth module surely this should fails
      3. Now remove the old custom module and use the corrected one.
      4. Check if this works now. (Currently: it seems the old config is used)
      5. Remove using ssoadm delete-svc -s iPlanetAMAuthSampleAuthService to cleanup the module
      6. Restart and see if this custom module deploys or not
      7. (Currently: it seems that the custom module is no longer in the choice to select and so it means the new custom module is not registered)

      It seems that ssoadm create-svc -X amAuthSampleAuth.xml will correct this but then it opposite to what the installation guides says not to do

      Expected behaviour
      The AMPlugin does not help to indicate issues with not registering the module and there is no clear way to cleanup the plugin registry. This causes one to still use ssoadm and probably ldap to cleanup the Plugin registry.
      
      Current behaviour
      If there is a past custom auth module being registered, it is likely that later custom module will not be updated and the user may not know it. The AMplugin upgrade() method also lack assisting feature to help unregister modules and double registering the auth module itself cause authentication failures.
      

      Work around

      1. We can delete-svc and create-svc for using ssoadm to correct any failing service config

      2. If we still want to start afresh, then for the sample, on top of removing the custom authentication use ldap to remove the dn: ou=<module>,ou=plugins,ou=default,ou=GlobalConfig,ou=1.0,ou=amPluginService,ou=services,dc=openam,dc=forgerock,dc=org and restart all servers. Then the AMPlugin should then work to install the custom auth module again

      dn: ou=org.forgerock.openam.examples.SampleAuthPlugin,ou=plugins,ou=default,ou=GlobalConfig,ou=1.0,ou=amPluginService,ou=services,dc=openam,dc=forgerock,dc=org
      objectClass: sunServiceComponent
      objectClass: top
      objectClass: organizationalUnit
      sunserviceID: plugin
      ou: org.forgerock.openam.examples.SampleAuthPlugin
      sunKeyValue: version=1.0.0
      sunsmspriority: 0
      

      Code analysis

      AMPlugin and the PluginLifeCycle lacks the part to uninstall. Also there is not much support to uninstall plugins using the provided API. (and there not much error handling – eg: What happens if we throw excecption ...)

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              chee-weng.chea C-Weng C
            • Votes:
              2 Vote for this issue
              Watchers:
              15 Start watching this issue

              Dates

              • Created:
                Updated: