sign/encrypt assertions attributes not being honoured

[Peter Schober]

* sshabbir <sshabbir at bmj.com> [2018-08-02 13:01]:
> >What value do they actually want in the NameID?  Your
> >attributeDefinition suggests you want to put an unscoped username
> >in the field.  If that is true, the format should not be
> >"transient".
> 
> The value required in NameID is the username attribute, and format
> needs to be "unspecified",
> urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified.

The general recommendation from this community is to not believe such
claims and try to send the expected data in any suitable format,
e.g. using the attribute's formal name (for the "uid" attribute that
would be "urn:oid:0.9.2342.19200300.100.1.1").

Only when you've determined that not to work should you configure the
system to use "unspecified".

> It seems my AttributeDefinition is incorrect, and not sure what
> default urn format is for "username". In our case username is
> unique, should I use "uid" urn format

No. An AttributeDefintion is for defining attributes. If you need to
define a NameID with a value based on an attribute you do that in the
NameID configuration, in conf/saml-nameid.xml, e.g.:

<bean parent="shibboleth.SAML2AttributeSourcedGenerator"
  p:omitQualifiers="true"
  p:format="urn:oid:0.9.2342.19200300.100.1.1"
  p:attributeSourceIds="#{ {'uid'} }" />

This would define a NameID of the given format (using the formal
attribute name for "uid" as an example; for the pathological case set
that to "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified",
instead) that gets its value from the AttributeDefinition with the
id="uid". So define the uid attribute first in your resolver, without
any references to NameIDs of their formats.

Then override the NameID predecence in conf/relying-party.xml and only
list the desired format (which you also defined above), and only for
that broken SP in question, e.g.:

<bean parent="RelyingPartyByName" c:relyingPartyIds="#{{'https://sp.example.org/entity'}}">
  <property name="profileConfigurations">
    <list>
      <bean parent="SAML2.SSO" p:nameIDFormatPrecedence="urn:oid:0.9.2342.19200300.100.1.1" />
    </list>
  </property>
</bean>

(Again change the format to unspecified if positively required.)

Testing all this is simple using the provided "aacli" tool, and
potentially reloading the AttributeResolver and NameID services from
the command line as needed (no restarting of the IDP necessary, no
logging in to the SP, no entering passwords, no watching log files, etc.):

Running the aacli with saml NameIDs shown:

$ /opt/shibboleth-idp/bin/aacli.sh --saml2 -n SOME_USERID -r SOME_SP_ENTITYID

Reloading the resolver after you've defined the uid attribute:

$ /opt/shibboleth-idp/bin/reload-service.sh -id shibboleth.AttributeResolverService

Reloading the NameID generation config after you've defined the
attribute-sourced NameID:

$ /opt/shibboleth-idp/bin/reload-service.sh -id shibboleth.NameIdentifierGenerationService

Depending on other settings in the IDP you may also have to release
the underlying attribute to the SP, so if in doubt release the "uid"
attribute to that SP in your attribute-filter.xml, too, and re-try.

-peter