LDAP additional attribute mappings description do not specify that they are for creation only

[Marcos Lobo]

Additional attribute mappings can be used to map ldap attributes to internal keystone attributes. This allows keystone to fulfill ldap objectclass requirements. List of additional LDAP attributes used for mapping additional attribute mappings for users (or projects). Attribute mapping format is <ldap_attr>:<model_attr>, where ldap_attr is the attribute in the LDAP entry and model_attr is the Identity API attribute. (list value).

So far so good. Now, following next steps:
1- Apply this patch https://review.openstack.org/#/c/91490/

2- Add this parameter to keystone.conf file
tenant_additional_attribute_mapping = objectCategory:notexistingfield1, whenChanged:notexistingfield2

3- Add 'objectCategory' and 'whenChanged' LDAP parameters to Project model on keystone/common/models.py
class Project(Model):
    required_keys = ('id', 'name', 'domain_id')
    optional_keys = ('description', 'enabled', 'objectCategory', 'whenChanged')

4- Restart keystone

5- Execute this in command line:
curl -H "X-Auth-Token:admin_token" http://localhost:5000/v3/projects

Everything works perfectly!. you can see the info of 'objectCategory' and 'whenChanged' LDAP parameters in the JSON string returned by CURL... and it should not (I think) works, because "notexistingfield1" and "notexistingfield2" are not real fields.

I have a mistake in the keystone.conf file and everything is working properly.

[Alexander Makarov (amakarov)]

As far as I understand, the aim is:

provide attribute validation for ldap to model attribute mapping

[Alexander Makarov (amakarov)]

Added required attribute validation to keystone.common.models.Model, but applying it resulted in many test failures.
Further analysis revealed that there are some algorythms depending on behaviour
such as saving/retrieving model instanses without some fields declared in a model as required.
So I had to fall back to warning instead of raising validation error.

Additional attribute mapping appeared not working at all:
  * documentation states following format: (<ldap_attr>:<model_key>,)*
  * bug description supposes (<model_key>:<ldap_attr>,)*
  * code converting LDAP request result to model didn't care about additional mapping as described

TODO:
1. keystone.common.models.Model.validate(only, strict)
2. rewrite keystone.common.ldap.core.BaseLdap._ldap_res_to_model() to inclute additionally mapped fields to the result

[Alexander Makarov (amakarov)]

Patch is on the way

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/118590

[Alexander Makarov (amakarov)]

https://review.openstack.org/118590

[Morgan Fainberg (mdrnstm)]

Discussed this with nkinder and it looks like this is a nice to have (and could have value) but shouldn't block Juno RC.

[Adam Young (ayoung)]

This mapping exists to aid in adding objects that have required fields. The best example is

assume that "cn", "sn", and "uid" are required in LDAP and the mappings in keystone are "id->uid", "name->cn"

 but what about "sn"? If keystone tries to do an add, it needs to supply something for the sn

The first line in the comment for these fields should read:

"List of additional LDAP attributes for required fields when creating new entities."

[OpenStack Infra (hudson-openstack)]

Change abandoned by Morgan Fainberg (<email address hidden>) on branch: master
Review: https://review.openstack.org/118590
Reason: administratively abandoning this change as there has been no further work on it.

[Steve Martinelli (stevemar)]

marking as invalid, since the options are deprecated, let's just remove them