Design for allowing IdP Administrators to update Attribute Mappings

We describe how external administrators (of federation IdPs or cloud using organisations) are recognised as being trusted to specify the organisational attributes that their users will present, the credential validation rules for these, and hence the user organisational attribute assignments that Keystone will accept. Furthermore they are also trusted to perform attribute mappings from these organisational attributes to a subset of the OpenStack attributes that will give the users permission to access the various OpenStack services. We also specify higher level API operations for managing attribute mappings

When Apache or another Web Container processes the Authentication, the environment variables passed through, such as REMOTE_USER, will not always map exactly to the attributes as exposed by the Identity API. For example, If Kerberos is used, the the REMOTE_USER field will come through with Principal@REALM, but the principal may contain characters other than the UserID, and the REALM will probably look like a FQDN but in all caps.

IN addition, Groups will come through in a variety of formats. SSL_ or NSS_ prefeixed variables from the parsing of X509 will sometimes have values that should map to groups in them. Other variables will be lists or maps that need to be expanded first.

The mapping is likely to be different based on the Identity Provider and Protocol combination. As such, dynamicallyt adding a new IdP or adding a new protocol to an IdP will require either the reuse of an existing mapping, or the generation of a new mapping.