nameid-format:unspecified for relying party

Baron Fujimoto baron at
Thu Jul 12 23:06:15 EDT 2018

On Thu, Jul 12, 2018 at 01:23:17PM +0000, Cantor, Scott wrote:
>> Am I misunderstanding though that I should be able to specify the
>> NameIDFormat via a RelyingParty override rather than specifying it in the SP's
>> metadata?
>Yes, as long as you're not trying to use the one "format that isn't a format" that people keep trying to use that's referenced in the subject line.
>> Per your ArcGIS documentation this works as expected.
>Being out of position in the metadata tends not to matter as much to the IdP if it's not schema validating, but I would be surprised that quoting it like that worked. That would be an interesting bug.

Argh, sorry, that was an artifact of cutting and pasting various configs while composing the reply.
The actual metadata's NameIDFormat was not quoted. I've also corrected the order for the NameIDFormat element having now found this reference <> (I didn't find examples of it in situ on the other documentation pages referencing NameIDFormat I'd been using).

>> It generates a transient format NameID in the Subject once again. The
>> documentation I'm using as references describes the RelyingParty
>> nameIDFormatPrecedence attribute as "A space delimited, ordered list of
>> name identifier formats" [1] and the logic (I think) to select the
>> NameIDFormat [2][3].
>They are equivalent and if you get different results, there's some fact not in evidence that means it isn't using the configuration you think it is.

Ok, I suspected that, so that's a useful confirmation. Any suggestions on what to look for to troubleshoot it?

Logs seem to indicate it picks up the relying party entry:

DEBUG [net.shibboleth.idp.relyingparty.impl.DefaultRelyingPartyConfigurationResolver:305] - Checking if relying party configuration is applicable
DEBUG [net.shibboleth.idp.relyingparty.impl.DefaultRelyingPartyConfigurationResolver:307] - Relying party configuration is applicable
DEBUG [net.shibboleth.idp.profile.impl.SelectRelyingPartyConfiguration:136] - Profile Action SelectRelyingPartyConfiguration: Found relying party configuration for request

Relying party:

    <RelyingParty id=""
        <ProfileConfiguration xsi:type="saml:SAML2SSOProfile" encryptAssertions="never" encryptNameIds="never" />

It resolves and filters attributes:

DEBUG [net.shibboleth.idp.attribute.resolver.impl.AttributeResolverImpl:206] - Attribute Resolver 'ShibbolethAttributeResolver': Final resolved attribute collection: [uid, ...]
DEBUG [net.shibboleth.idp.attribute.filter.impl.AttributeFilterImpl:108] - Attribute filtering engine 'ShibbolethAttributeFilter'  Beginning process of filtering the following 33 attributes: [uid, ...]
DEBUG [net.shibboleth.idp.attribute.filter.AttributeFilterPolicy:125] - Attribute Filter Policy 'ArcGIS'  Checking if attribute filter policy is active
DEBUG [net.shibboleth.idp.attribute.filter.policyrule.filtercontext.impl.AttributeRequesterPolicyRule:54] - Attribute Filter '/AttributeFilterPolicyGroup:ShibbolethFilterPolicy/PolicyRequirementRule:_14ef7b7c3bacb4f701263daa29d7cfdc': Found attribute requester:
DEBUG [net.shibboleth.idp.attribute.filter.AttributeFilterPolicy:132] - Attribute Filter Policy 'ArcGIS'  Policy is active for this request
DEBUG [net.shibboleth.idp.attribute.filter.AttributeFilterPolicy:159] - Attribute Filter Policy 'ArcGIS'  Applying attribute filter policy to current set of attributes: [uid, ...]
DEBUG [net.shibboleth.idp.attribute.filter.impl.AttributeFilterImpl:167] - Attribute filtering engine 'ShibbolethAttributeFilter': 1 values for attribute 'uid' remained after filtering

Encodes filtered attributes and builds AttributeStatement:

DEBUG [net.shibboleth.idp.saml.profile.impl.BaseAddAttributeStatementToAssertion:229] - Profile Action AddAttributeStatementToAssertion: Attempting to add an AttributeStatement to outgoing Assertion
DEBUG [net.shibboleth.idp.saml.saml2.profile.impl.AddAttributeStatementToAssertion:174] - Profile Action AddAttributeStatementToAssertion: Attempting to encode attribute uid as a SAML 2 Attribute
DEBUG [net.shibboleth.idp.saml.saml2.profile.impl.AddAttributeStatementToAssertion:188] - Profile Action AddAttributeStatementToAssertion: Encoding attribute uid as a SAML 2 Attribute
DEBUG [net.shibboleth.idp.saml.attribute.encoding.AbstractSAMLAttributeEncoder:154] - Beginning to encode attribute uid
DEBUG [net.shibboleth.idp.saml.attribute.encoding.SAMLEncoderSupport:73] - Encoding value baron of attribute uid
DEBUG [net.shibboleth.idp.saml.attribute.encoding.AbstractSAMLAttributeEncoder:191] - Completed encoding 1 values for attribute uid
2018-07-12 10:53:36,142 - DEBUG [net.shibboleth.idp.saml.saml2.profile.impl.AddAttributeStatementToAssertion:118] - Profile Action AddAttributeStatementToAssertion: Adding constructed AttributeStatement to Assertion _04f66b8ab9ac05fe23f03c2ae7b885c1 

But when it gets to DefaultNameIdentifierFormatStrategy:

DEBUG [net.shibboleth.idp.saml.profile.logic.DefaultNameIdentifierFormatStrategy:102] - No ProfileConfiguraton available (or not an AuthenticationProfileConfiguration)
DEBUG [net.shibboleth.idp.saml.profile.logic.DefaultNameIdentifierFormatStrategy:110] - No formats specified in configuration or in metadata, returning default

It says "No formats specified in configuration" and I wind up with the transient NameID format. Don't the DefaultRelyingPartyConfigurationResolver and SelectRelyingPartyConfiguration logs above show that it should be using the relying-party entry with id=""? If so, is that the correct way to specify the nameIDFormatPrecedence? Not sure what else to look for.

Baron Fujimoto <baron at> :: UH Information Technology Services
minutas cantorum, minutas balorum, minutas carboratum desendus pantorum

More information about the users mailing list