[OPENAM-3296] ssoadm uses LDAP auth module first to authenticate amadmin Created: 12/Nov/13  Updated: 20/Nov/16  Resolved: 23/Jan/15

Status: Resolved
Project: OpenAM
Component/s: CLI
Affects Version/s: 10.0.0-EA, 10.0.0, 10.0.1, 10.1.0-Xpress, 11.0.0
Fix Version/s: 11.0.3, 12.0.1, 13.0.0

Type: Bug Priority: Major
Reporter: Bernhard Thalmayr Assignee: Kamal Sivanandam
Resolution: Fixed Votes: 0
Labels: EDISON, release-notes
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates
is related to OPENAM-816 ssoadm authentication depends on the ... Resolved
Sprint: Sprint 76 - Sustaining
Support Ticket IDs:

 Description   

ssoadm always tries to authenticate 'amadmin' using module LDAP for module based auth. This leads to the following log entry within 'amAuthentication.error' (or database table if DBHandler is used)

"2013-11-13 00:30:54"   "Login Failed|module_instance|LDAP"     "Not Available" "Not Available" 127.0.0.1       INFO    dc=openam,dc=forgerock,dc=org   "cn=dsameuser,ou=DSAME Users,dc=openam,dc=forgerock,dc=org"     AUTHENTICATION-268      LDAP    "Not Available" 127.0.0.1

and is quite confusing for users monitoring the log files.

Authentiator.java
    private AuthContext sessionBasedLoginInternal(
        CommandManager mgr,
        String bindUser,
        String bindPwd
    ) throws CLIException {
        AuthContext lc = null;
        String authModule = SystemProperties.get(DEFINED_AUTH_MODULE);

        if (authModule != null) {
            lc = sessionBasedLoginInternal(mgr, bindUser, bindPwd, authModule);
        } else {
            /*
             * try LDAP and then DataStore
             */
            try {
                lc = sessionBasedLoginInternal(mgr, bindUser, bindPwd,
                    LDAP_AUTH_MODULE);
            } catch (CLIException e) {
                lc = sessionBasedLoginInternal(mgr, bindUser, bindPwd,
                    FLATFILE_AUTH_MODULE);
            }
        }
        return lc;
    }

ldap auth module base auth should be removed as it will most like not succeed and 'amadmin' is stored in special repo.



 Comments   
Comment by Mark de Reeper [ 13/Nov/13 ]

Maybe the original thinking was that it should cover the case where the user may not be amadmin but an ordinary user that has been given delegated admin rights. Perhaps it should try the DataStore first.

Comment by Bernhard Thalmayr [ 13/Nov/13 ]

Even when thinking about 'delegated admin' (what about sub-realm admins?!?) the authentication method may not be LDAP, so choosing an arbitrary module seems to be questionable.

To be consistent with the GUI, service based auth should be used as it is done when accessing '<DEPLOYMENT_URI>/console' which is actually the correct way to access the console ...

BUT what if the 'admin auth chain' is not using a <NameCallback>, <PasswordCallback> , but cert based auth?

As 'ssoadm' requires OS level access to the system where OpenAM is deployed it's quite unlikely a 'delegated admin' is using 'ssoadm', so using 'datastore' will most likely cover 99% of the use cases.

Comment by Peter Major [X] (Inactive) [ 21/Jan/15 ]

This is quite similar to OPENAM-816.
The proposal is the following:

  • by default the order will be DataStore first, then LDAP (to keep backwards compatibility)
  • OPENAM-816 will introduce two new settings that will allow users to specify the preferred authentication mechanism using JVM properties defined in the ssoadm {.bat}

    scripts.

Comment by Kamal Sivanandam [ 23/Jan/15 ]

Fixed in - revision 12174, 12178 and 12182

Comment by Sarris Overbosch [ 26/Feb/15 ]

Now I am a tidy person and remove all default not needed authentication modules and even remove the (embedded) datastore if I am not using it. This makes further configuration using ssoadm fail, giving the message "No plug-ins configured for this operation", which is probably caused by the way this is implemented?

But OPENAM-816 introduce two new parameters in which you define an module to be used by ssoadm to authenticate and thus solve the problem

Comment by Peter Major [X] (Inactive) [ 26/Feb/15 ]

This fix isn't available in any of the stable releases, are you sure you are running into this? Also note that amadmin needs to authenticate somewhere, and amadmin can only authenticate using the DataStore authentication module.

Comment by Sarris Overbosch [ 26/Feb/15 ]

Yes, as far as I can see.

Steps to reproduce would be, using ssoadm:
1 Install and configure OpenAM
2 remove all default authentication modules except datastore from /
3 remove embedded datastore (as we don't need it because we only want to manage session and nothing more, profile ignored) from /
4 create new realm
5 change some attributes (set-realm-svc-attrs -s iPlanetAMAuthService -e "new realm" -D attr_file)

Step 3 is probably causing these problems, as when we do not delete the embedded datastore everything just works fine because the the datastore module has a backing datastore (I assume)

Comment by Peter Major [X] (Inactive) [ 26/Feb/15 ]

That description seems to be more related to OPENAM-1323 . Session service is not the only one having that problem.

Comment by Sarris Overbosch [ 26/Feb/15 ]

Indeed

Generated at Sat Oct 24 00:20:36 UTC 2020 using Jira 7.13.12#713012-sha1:6e07c38070d5191bbf7353952ed38f111754533a.