[Satosa-dev] hasher microservice

Hello, On Tue, 27 Nov 2018 at 20:11, Paul Caskey <pcaskey at internet2.edu> wrote: The hasher microservice replaces a mechanism that existed in SATOSA for no good reason. SATOSA would unconditionally hash the name-id value (used to be called user_id, changed to subject_id) before giving it to the response microservices and finally the frontend that would forward the authn-response to the SP. This resulted in problems and was moved out as a microservice. In the form of a microservice it can now be chosen whether this should take place or not; and the configuration has been extended to define if this should take place when a specific SP-entityid is met. Along with this, some configuration options are no longer needed. One of them is USER_ID_HASH_SALT. As SATOSA is not performing the hash, it does not need that configuration option anymore. If there is a reason that you need that hash to take place, the USER_ID_HASH_SALT should now be defined at the hasher microservice configuration and it can again be defined to different value per SP-entityid. If you do not have such a need for the hash, you can just remove the configuration option from the main configuration file ('proxy_conf.yaml') and the warning will be gone. (The same holds for the 'hash:' configuration option that provided a list of attributes whose values would be hashed. This option used to be defined in 'internal_attributes.yaml'.) There is an example configuration of the hasher microservice here: https://github.com/IdentityPython/SATOSA/blob/master/example/plugins/micros… Cheers, -- Ivan c00kiemon5ter Kanakarakis >:3