Attribute resolver warning on start-up

Wessel, Keith kwessel at illinois.edu
Thu Jul 2 14:40:35 EDT 2015


Thanks, Scott and Peter, that helps.

I think I might have the wrong encoding listed in the metadata being generated by our local federation registry. Is this the kind of metadata line that could be causing the problem?

        <RequestedAttribute FriendlyName="eduPersonScopedAffiliation" Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.9" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" isRequired="false"/>

Keith

-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: Thursday, July 02, 2015 12:58 PM
To: Shib Users
Subject: Re: Attribute resolver warning on start-up

On 7/2/15, 1:32 PM, "users on behalf of Wessel, Keith" <users-bounces at shibboleth.net on behalf of kwessel at illinois.edu> wrote:
>
>Yet we get valid scoped attribute values for eduPersonScopedAffiliation released to SPs. Below is my definition from attribute-resolver.xml. What's causing this warning?

You have metadata loaded that has <RequestedAttribute> elements in it that have invalid (unscoped) values.

The message is coming from a new subsystem that lets us map SAML attributes back into IdPAttributes, analagously to what an SP does, but we don't have a new configuration layer for that yet, we just automated it all by looking at your resolver rules. When you tell the resolver that "urn:oid:1.3.6.1.4.1.5923.1.1.1.9" is being encoded as a scoped attribute, you're also telling the "reverse mapper" that it should treat the values as scoped if it seems them in metadata.

What it's basically telling you is there's a semantic issue with the metadata.

-- Scott

-- 
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net


More information about the users mailing list