glassfish
  1. glassfish
  2. GLASSFISH-20131

LDAP-based admin authorization does not work with group names other than asadmin

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Works as designed
    • Affects Version/s: 4.0
    • Fix Version/s: None
    • Component/s: admin
    • Labels:
      None

      Description

      If you use the configure-ldap-for-admin command to use LDAP for admin security then authentication works but authorization does not unless the LDAP group you use is "asadmin."

        Activity

        Hide
        Tim Quinn added a comment -

        This problem is a side-effect of the more stringent admin authorization that's now in place. That logic currently detects that an authenticated user is an administrator by checking the Subject for a Principal with name "asadmin." This works fine for the default file-based realm but not for LDAP if the group name that represents GlassFish administrators is some other group.

        Show
        Tim Quinn added a comment - This problem is a side-effect of the more stringent admin authorization that's now in place. That logic currently detects that an authenticated user is an administrator by checking the Subject for a Principal with name "asadmin." This works fine for the default file-based realm but not for LDAP if the group name that represents GlassFish administrators is some other group.
        Hide
        Tim Quinn added a comment -

        Actually the LDAP group name mapping should already be taking care of converting the user-configured group name to asadmin. Still looking. It might be a problem in the set-up of the test LDAP server being used for the test.

        Show
        Tim Quinn added a comment - Actually the LDAP group name mapping should already be taking care of converting the user-configured group name to asadmin. Still looking. It might be a problem in the set-up of the test LDAP server being used for the test.
        Hide
        Tim Quinn added a comment -

        It now looks as if the data in the sample LDAP directory did not add the admin user as a member to the configured group. GlassFish searches for the already-authenticated user by asking the group for the unique member with the uid of the user. In this case because the group was there but had no members, the LDAP query returned no results so the Subject in GlassFish did not have a Principal for the administrator group, so that user was denied access to admin functions.

        I am closing this because the code seems to be working as designed.

        Show
        Tim Quinn added a comment - It now looks as if the data in the sample LDAP directory did not add the admin user as a member to the configured group. GlassFish searches for the already-authenticated user by asking the group for the unique member with the uid of the user. In this case because the group was there but had no members, the LDAP query returned no results so the Subject in GlassFish did not have a Principal for the administrator group, so that user was denied access to admin functions. I am closing this because the code seems to be working as designed.

          People

          • Assignee:
            Tim Quinn
            Reporter:
            Tim Quinn
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: