Not totally convinced about this one. If I understand correctly, this is about username mapping -- if Keystone is configured to rely on REMOTE_USER to give it usernames, it will consider REMOTE_USERs john and john@* to all point to the same Keystone user "john".
If properly documented, that could be seen as a feature. If not, that could be seen as a bug (you have no way to access Keystone user john@* in a REMOTE_USER-enabled setup). If it's a bug, it has some potential security impact that we should document, but I could go with OSSN + fix in next, especially if the fix ends up breaking existing setups actually *relying* on the mapping.
Not totally convinced about this one. If I understand correctly, this is about username mapping -- if Keystone is configured to rely on REMOTE_USER to give it usernames, it will consider REMOTE_USERs john and john@* to all point to the same Keystone user "john".
If properly documented, that could be seen as a feature. If not, that could be seen as a bug (you have no way to access Keystone user john@* in a REMOTE_USER-enabled setup). If it's a bug, it has some potential security impact that we should document, but I could go with OSSN + fix in next, especially if the fix ends up breaking existing setups actually *relying* on the mapping.