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

Bug #1336769 reported by Marcos Lobo on 2014-07-02
30
This bug affects 4 people
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)
Low
Alexander Makarov

Bug Description

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.

Dolph Mathews (dolph) on 2014-07-03
tags: added: ldap
Changed in keystone:
importance: Undecided → Low
Alexander Makarov (amakarov) wrote :

As far as I understand, the aim is:

provide attribute validation for ldap to model attribute mapping

Changed in keystone:
assignee: nobody → Alexander Makarov (amakarov)
Alexander Makarov (amakarov) wrote :

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) wrote :

Patch is on the way

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

Changed in keystone:
status: New → In Progress
Dolph Mathews (dolph) on 2014-09-09
tags: added: juno-rc-potential
Morgan Fainberg (mdrnstm) wrote :

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

tags: removed: juno-rc-potential
Adam Young (ayoung) wrote :

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

summary: - LDAP additional attribute mappings do not care about model attribute
+ LDAP additional attribute mappings description do not specify that they
+ are for creation only

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) wrote :

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

Changed in keystone:
status: In Progress → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers