Federation Unable to handle multiple groups

[Krishna]

I'm using OIDC federated authentication, I'm able to use the mapping json to do ephemeral user authentication.
Following is my mapping json:

[
    {
        "local": [
            {
                      "user": {
                        "name": "{0}"
                    },

                        "group": {
                            "id": "{1}"
                },
   "domain": {
                                "name": "default"
                            }

            }
        ],
        "remote": [
  {
                "type": "HTTP_OIDC_EMAIL"
                },
  {
                "type": "HTTP_OIDC_GROUP"
                },
                {
                "type" : "HTTP_OIDC_ISS",
                "any_one_of": [
                        "https://myidp.cisco.com/oauth2"
                ]
                }

        ]
    }
 ]

and when tested with the keystone-mange mapping, I'm able to see multiple groups properly.
output of Keystone-mapping verification.

{
  "group_ids": [
    "5207b97776914a6b9f99e1c985533863,23a70aa1af5f4439afb628a10f53ade3"
  ],
  "user": {
    "domain": {
      "id": "Federated"
    },
    "type": "ephemeral",
    "name": "<email address hidden>"
  },
  "group_names": []
}

However, when the same flow is executed thru the OIDC I get the following error message

{"error": {"message": "Group ['5207b97776914a6b9f99e1c985533863', '23a70aa1af5f4439afb628a10f53ade3'] returned by mapping fed_mapping was not found in the backend. (Disable debug mode to suppress these details.)", "code": 500, "title": "Internal Server Error"}}

I looked into the util.py code and printed the groups that were coming into the validate_groups_in_backend function.

validate_groups_in_backend /opt/stack/keystone/keystone/contrib/federation/utils.py:258
2016-04-26 12:38:46.750572 25124 DEBUG keystone.contrib.federation.utils [req-b54b5075-a4e5-46fc-a600-f8a07cfaf2cf - - - - -] printing group_ids list [u"['5207b97776914a6b9f99e1c985533863', '23a70aa1af5f4439afb628a10f53ade3']"] validate_groups_in_backend /opt/stack/keystone/keystone/contrib/federation/utils.py:259
2016-04-26 12:38:46.750704 25124 DEBUG keystone.contrib.federation.utils [req-b54b5075-a4e5-46fc-a600-f8a07cfaf2cf - - - - -] printing group_id ['5207b97776914a6b9f99e1c985533863', '23a70aa1af5f4439afb628a10f53ade3'] validate_groups_in_backend /opt/stack/keystone/keystone/contrib/federation/utils.py:260
2016-04-26 12:38:47.092780 25124 WARNING keystone.common.wsgi [req-b54b5075-a4e5-46fc-a600-f8a07cfaf2cf - - - - -] Group ['5207b97776914a6b9f99e1c985533863', '23a70aa1af5f4439afb628a10f53ade3'] returned by mapping openam_mapping was not found in the backend. (Disable debug mode to suppress these details.)
(END)

it looks like the list is formed incorrectly
[u"['5207b97776914a6b9f99e1c985533863', '23a70aa1af5f4439afb628a10f53ade3']"]

it should have been
[u'5207b97776914a6b9f99e1c985533863', u'23a70aa1af5f4439afb628a10f53ade3']

Thanks,
Krishna

[Krishna (kathurko)]

Upon talking to Steve and Henry, This is really not a bug.
instead , to get the list of groups, group_ids have to be used.
[
    {
        "local": [
            {
                      "user": {
                        "name": "{0}"
                    },

                        "group_ids": "{1}"

            }
        ],
        "remote": [
                {
                "type": "HTTP_OIDC_EMAIL"
                },
                {
                "type": "HTTP_OIDC_GROUPS"
                },
                {
                "type" : "HTTP_OIDC_ISS",
                "any_one_of": [
                        "https://idp.cisco.com/oauth2"
                ]
                }

        ]
    }
 ]

However, this only works in Mitaka since group_ids is not handled in liberty code.
since this is an important feature,
i'd like to request the utils.py code that handles group_ids in mitaka to be back ported to liberty.

THanks,
Krishna

[Dolph Mathews (dolph)]

So, HTTP_OIDC_GROUP contains a comma-delimited list of IDs?

[Dolph Mathews (dolph)]

Our stable branch policy dictates that we don't backport features, and an API-impacting one would be the first to be denied in review.

Sadly, it looks like a significant oversight in the original implementation, though.