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.
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.