Microservices: Unexpected behaviour of Hasher & HashProcessor

[github-canni]

Code Version

Satosa 8.2.0 (docker), running an saml2 frontend and oidc backend, proxy from OIDC to SAML

Expected Behavior

• (1) Hasher and HashProcessor produce the same hash values (under the same input circumstances)
• (2) Hasher and HashProcessor can produce a hash value of attribute values which came from primary identifier processor

Current Behavior

(1) Hasher and HashProcessor, e.g.

• same input string, e.g.: 2b27510c-6297-311b-7004-ab7113390135
• same salt, e.g.: qiAUwGorlHrKjbWSB68ZIelO7KC6VrZQ8wpoEVdzPb1D9ZhD
• same hash alg, e.g.: sha224 but: Hasher and HashProcessor, both configured to hash that attribute containing the input string value, produce different output values (of course they were not used at the same time but tested separately) [this could be due to internals, e.g. prepending vs. appending salt, using different libs etc.]

(2) Trying to hash an attribute, which was scoped and generated by the processor "primary identifier", return unexpected results:

• (2.1) HashProcessor: fails with type error

satosa|   File "/usr/local/lib/python3.11/site-packages/satosa/micro_services/attribute_processor.py", line 60, in process
satosa|     instance.process(data, attribute, **kwargs)
satosa|   File "/usr/local/lib/python3.11/site-packages/satosa/micro_services/processors/hash_processor.py", line 31, in process
satosa|     attributes[attribute][0] = value_hashed
satosa|     ~~~~~~~~~~~~~~~~~~~~~^^^
satosa| TypeError: 'str' object does not support item assignment

• (2.2) Hasher: produces multiple hashed strings as output values, seperated with a semicolon, some of those are identical, some differ

Possible Solutions

(1) Align Hasher / Hashprocessor outputs with preserved backwards compatibility, e.g. by providing a new parameter to align hash functions (rewrite/align/split internal hashing processes)

(2) There might be a fix for the "primary identifier" processor (which might be the root cause of that issue) - otherwise a fix for Hasher and HashProcessor could be provided

Workarounds

Of course own / modified / custom modules could be written. But usually I try to find a way with default functions.

(1) Use either or, not both. The issue is that Attribute Processor > HashProcessor cannot update/modify subject_id. In the microservice "hasher" the subject_id can be hashed as well among with the attributes. The HashProcessor seem only to be able to hash attributes from the internal map (I might be wrong here and would love to get feedback on that matter).

(2) Do not hash the target attribut produced from "primary identifier" with Hasher microservice but with AtributeProcessor > HashProcessor. There you could use "ScopeProcessor" appending an arbitrary string before hashing with the HashProcessor. This is a workaround as HashProcessor would fail otherwise.

Steps to Reproduce

(1)

1. Hash an input string with hasher and hashprocessor, using the same input string, salt and algorithm, compare outputs

(2)

1. Use microservice "primary identifier" with add_scope "issuer_entityid", e.g. producing '2b27510c-6297-311b-7004-ab7113390135https://host/oidc/auth', e.g. let the micrososervice place the generated identifier in attribute 'uid'
2. Then use Hasher or HashProcessor to hash the 'uid' to see results mentioned above