Null/Empty value encoding support for requested attribute (ref. saml-core-2.0 spec par. 2.7.3.1.1)

Diego Pietralunga diego.pietralunga at lepida.it
Thu Sep 19 05:41:43 EDT 2019


Hello.

I am investigating a use case for which we are requested to adhere
"strictly" to the aforementioned SAML2 specification (par 2.7.3.1.1)
for attribute value in case of an attribute whose value is "empty" at
the IDP.
This may be a little tricky to explain and I forewarn that I do not
feel completely in agreement with the use case but...

We are talking of a case where it is *not* the attribute (string) which is
"null"  or missing (as an entity) but in a case where the attribute
*has* value "null/empty"(*).
In this case, we currently release "nothing" to the SP (meaning no xml
concerning this attribute).

The SP has the attribute as requested in his metadata and perform some
"sanity" checks upon access (like counting the incoming attributes).

So, for the sake of the example, let's say that the attribute is "shoeSize" (**)
and that not of all our users we have this data, and also that some SPs
request this in the response with an attribute value that may be an
empty xml tag, so something like :

<saml2:Attribute Name="shoeSize"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                <saml2:AttributeValue/>
</saml2:Attribute>


1) Am I correct that Shibboleth IDP does not support this? If so, why?
2) Am I correct that this should be handled by an Encoder *only*, or
there may be other things to take care of?
3) In case there is no direct IDP support (or viable workarounds) and we
fulfill the requirement, should this be done by implementing some
kind of... "Saml2NilFriendlyStringEncoder" and try to configure it to
handle xsi:type="SAML2String" ?
4)In the general case where we never are able to collect (or release
the value of) shoeSize attribute, maybe we should think instead of
implementing some kind of "Saml2NilEncoder" to handle xsi:nil  always?
5) As a possible workaround, I also thought of a scripted attribute,
but I am pretty sure that the current encoder behaviour cannot be
overridden in this way. Is that so?

We are on Shibboleth 3.3.x and the current config of shoeSize in
attribute-filter.xml is
<PermitValueRule xsi:type="AttributeInMetadata" onlyIfRequired="false"/>
handled by a "SAML2String" in attribute-resolver.xml.

Can you give some suggestions, please?


Regards,

Diego

EDIT!
While I was drafting this and about to send, I found this [1] which is
about 6 years ago and it is very related and explains something. I
am still sending the original mail, asking if something has changed in
the meantime.






[1] https://marc.info/?l=shibboleth-users&m=138627005822487&w=2


(*) Yes, I know that each one may have a slightly different subcase, in
general, anyway datastore is on Oracle, for which they are treated the
same.

(**) Could also be something like mobilePhone, that the user may not
have or refusing to give.


More information about the users mailing list