HBase
  1. HBase
  2. HBASE-10919

[VisibilityController] ScanLabelGenerator using LDAP

    Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 2.0.0
    • Component/s: None
    • Labels:
      None

      Description

      A ScanLabelGenerator that queries an external service, using the LDAP protocol, for a set of attributes corresponding to the principal represented by the request UGI, and converts any returned in the response to additional auths in the effective set.

      1. slides-10919.pdf
        101 kB
        Andrew Purtell

        Issue Links

          Activity

          Hide
          Andrew Purtell added a comment -

          No patch or progress on this issue. Unscheduling from releases until we have one.

          Show
          Andrew Purtell added a comment - No patch or progress on this issue. Unscheduling from releases until we have one.
          Hide
          Andrew Purtell added a comment -

          Moving out of 0.98.7

          Show
          Andrew Purtell added a comment - Moving out of 0.98.7
          Hide
          Misty Stanley-Jones added a comment -

          Potential doc text for this for when this is committed, to go around line 1164 of security.xml:

          <!--An idea discussed in <link
          xlink:href="https://issues.apache.org/jira/browse/HBASE-10919">HBASE-10919</link> makes it
          possible to query an LDAP directory for a set of attributes corresponding to the principal
          represented by the request, and convert attributes returned in the response to additional
          auths in the effective set, as shown below. ScanLabelGenerators could be specified in the
          configuration as a comma-separated list of class names. At the time of this writing, the
          feature is not completed.</para>
          <figure>
          <title>ScanLabelGenerator Diagram</title>
          <mediaobject>
          <imageobject>
          <imagedata fileref="LDAPScanLabelGenerator.png" width="100%"/>
          </imageobject>
          <textobject>
          <para>The <code>LDAPScanLabelGenerator</code> results could possibly be combined with
          the <code>DefaultScanLabelGenerator</code>, to generate the full set of effective
          labels for the principal.</para></textobject>
          </mediaobject>
          </figure>-->

          Show
          Misty Stanley-Jones added a comment - Potential doc text for this for when this is committed, to go around line 1164 of security.xml: <!--An idea discussed in <link xlink:href="https://issues.apache.org/jira/browse/HBASE-10919"> HBASE-10919 </link> makes it possible to query an LDAP directory for a set of attributes corresponding to the principal represented by the request, and convert attributes returned in the response to additional auths in the effective set, as shown below. ScanLabelGenerators could be specified in the configuration as a comma-separated list of class names. At the time of this writing, the feature is not completed.</para> <figure> <title>ScanLabelGenerator Diagram</title> <mediaobject> <imageobject> <imagedata fileref="LDAPScanLabelGenerator.png" width="100%"/> </imageobject> <textobject> <para>The <code>LDAPScanLabelGenerator</code> results could possibly be combined with the <code>DefaultScanLabelGenerator</code>, to generate the full set of effective labels for the principal.</para></textobject> </mediaobject> </figure>-->
          Hide
          Andrew Purtell added a comment -

          Moving out of .6

          Show
          Andrew Purtell added a comment - Moving out of .6
          Hide
          Andrew Purtell added a comment -

          I've been involved in offline discussions on this issue. Seems likely to be eventually implemented for 0.98 but toward the latter lifetime of the release branch. If a patch shows up we can target the latest 0.98 SNAPSHOT. For now moving out of .5 to .6.

          Show
          Andrew Purtell added a comment - I've been involved in offline discussions on this issue. Seems likely to be eventually implemented for 0.98 but toward the latter lifetime of the release branch. If a patch shows up we can target the latest 0.98 SNAPSHOT. For now moving out of .5 to .6.
          Hide
          Andrew Purtell added a comment -

          Moving to 0.98.4. We don't have time for this to make the .3 release.

          Show
          Andrew Purtell added a comment - Moving to 0.98.4. We don't have time for this to make the .3 release.
          Hide
          Andrew Purtell added a comment -

          This one is going to need a design document. In the meantime, let me attach draft slides discussing this topic from an upcoming presentation at HBaseCon.

          Show
          Andrew Purtell added a comment - This one is going to need a design document. In the meantime, let me attach draft slides discussing this topic from an upcoming presentation at HBaseCon.
          Hide
          Andrew Purtell added a comment -

          Move to 0.98.3

          Show
          Andrew Purtell added a comment - Move to 0.98.3
          Hide
          Andrew Purtell added a comment -

          Another useful configuration option would be one where, if enabled, any auths found in the pending effective set not corresponding to any attribute found on LDAP object(s) would be dropped.

          Show
          Andrew Purtell added a comment - Another useful configuration option would be one where, if enabled, any auths found in the pending effective set not corresponding to any attribute found on LDAP object(s) would be dropped.
          Hide
          Andrew Purtell added a comment -

          We could start by doing something similar to Hadoop's LDAP group mapper (see org.apache.hadoop.security.LdapGroupsMapping). It would be familiar to admins who may have set that up before already.

          You configure this provider with a user and password used to bind to the LDAP server, and the location of the LDAP server. Then, the base distinguished name to use for searches, and a filter expression to apply when searching for user objects, e.g.

          (&(objectClass=user)(cn={0}))
          

          We would then need to add new configuration for filtering out the object attributes we are not interested in. Any attributes remaining could become auths.

          Because the SLGs run inside the RegionServer processes with superuser privileges, it would be possible for them to add new labels to the system label dictionary dynamically as needed. Therefore the universe of labels/auth names would not need to be defined up front for new attributes found on relevant objects returned from LDAP searches.

          Because this SLG would otherwise want to query LDAP for every user request, we would want to introduce caching of LDAP query responses with a limited lifetime, perhaps 5 or 10 minutes, and reuse the results of previous searches until they expire.

          Show
          Andrew Purtell added a comment - We could start by doing something similar to Hadoop's LDAP group mapper (see org.apache.hadoop.security.LdapGroupsMapping). It would be familiar to admins who may have set that up before already. You configure this provider with a user and password used to bind to the LDAP server, and the location of the LDAP server. Then, the base distinguished name to use for searches, and a filter expression to apply when searching for user objects, e.g. (&(objectClass=user)(cn={0})) We would then need to add new configuration for filtering out the object attributes we are not interested in. Any attributes remaining could become auths. Because the SLGs run inside the RegionServer processes with superuser privileges, it would be possible for them to add new labels to the system label dictionary dynamically as needed. Therefore the universe of labels/auth names would not need to be defined up front for new attributes found on relevant objects returned from LDAP searches. Because this SLG would otherwise want to query LDAP for every user request, we would want to introduce caching of LDAP query responses with a limited lifetime, perhaps 5 or 10 minutes, and reuse the results of previous searches until they expire.

            People

            • Assignee:
              Unassigned
              Reporter:
              Andrew Purtell
            • Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:

                Development