Reading binary attributes, for example objectGUID, from the IdRepo cache not always returning valid values

This was seen when making use of the ;binary feature of the default SAML2 attribute mapper to read the objectGUID from AD to include as a base64 value in the Assertion.

When using the caching IdRepo, the attributes get cached in an instance of CacheBlockBase which maintains a separate cache for either string or binary attributes but often the attributes are loaded in one hit and there is no differentiation between binary or string values so they end up in the string cache. Later when a binary attribute is requested and it is found in the string cache, it is converted to a byte array and returned, this conversion is not always correct so you end up with a binary value that is not the same as the original.

The fix is to not return any cached string or binary attributes that are not held in the appropriate internal cache of CacheBlockBase which forces the attribute value to be re-loaded after which it is placed into the correct internal cache for later use.