Issues releasing Static Attributes with IdP 2.3.4

[Dan McLaughlin]

Since 2.1.5 we've defined and released Static Attributes. Today we
upgraded one of our IDP's from 2.3.3 to 2.3.4 and all of the Static
Attributes are no longer being released by the IdP. If I enable debug
logging I can see the Attribute Filter process the attribute, but
that's the last I see mention of the Static Attribute anywhere in the
logs. I diff'd our config files looking for typos between 2.3.3 and
2.3.4 there is no difference (that I could find), and if I put 2.3.3
back it starts releasing the attributes again. This leads me to
believe there has been some change in 2.3.4 that is affecting the
release of Static Attributes. Has anyone else seen issue releasing
static attributes in IdP 2.3.4?

Here is an example of how we are releasing static attributes...

#################
attribute-resolver.xml
#################

<!-- Static Attribute Definition -->

...
  <resolver:AttributeDefinition id="AgencyID" xsi:type="ad:Simple"
sourceAttributeID="MyStaticAttribute">    <resolver:Dependency
ref="MYSTATICDC" />
    <resolver:AttributeEncoder xsi:type="enc:SAML2String"
name="MyStaticAttribute" friendlyName="MyStaticAttribute" />
</resolver:AttributeDefinition>
...

<!-- Static Data Connectors -->

<resolver:DataConnector id="MYSTATICDC" xsi:type="dc:Static">
<dc:Attribute id="MyStaticAttribute">
<dc:Value>1234</dc:Value>
</dc:Attribute>
</resolver:DataConnector>

##############
attribute-filter.xml
##############

<afp:AttributeFilterPolicy id="releaseToAnyone">
<afp:PolicyRequirementRule xsi:type="basic:ANY" />
...
<afp:AttributeRule attributeID="MyStaticAttribute">
<afp:PermitValueRule xsi:type="basic:ANY" />
</afp:AttributeRule>

</afp:AttributeFilterPolicy>

Here is the process log for the IdP showing the MyStaticAttribute
passing the permit value rule, but that's the last time you ever see
mention of it again.

15:27:49.965 - DEBUG
[edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:71]
- shibboleth.AttributeFilterEngine filtering 7 attributes for
principal myuser
15:27:49.965 - DEBUG
[edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:130]
- Evaluating if filter policy releaseToAnyone is active for principal
myuser
15:27:49.965 - DEBUG
[edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:139]
- Filter policy releaseToAnyone is active for principal myuser
15:27:49.965 - DEBUG
[edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:163]
- Processing permit value rule for attribute uid for principal myuser
15:27:49.965 - DEBUG
[edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:163]
- Processing permit value rule for attribute email for principal
myuser
15:27:49.965 - DEBUG
[edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:163]
- Processing permit value rule for attribute HexGUID for principal
myuser
15:27:49.965 - DEBUG
[edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:163]
- Processing permit value rule for attribute givenName for principal
myuser
15:27:49.965 - DEBUG
[edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:163]
- Processing permit value rule for attribute surname for principal
myuser
15:27:49.965 - DEBUG
[edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:163]
- Processing permit value rule for attribute telephoneNumber for
principal myuser
15:27:49.965 - DEBUG
[edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:163]
- Processing permit value rule for attribute MyStaticAttribute for
principal myuser
15:27:49.965 - DEBUG
[edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:130]
- Evaluating if filter policy releaseTransientIdToAnyone is active for
principal myuser
15:27:49.965 - DEBUG
[edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:139]
- Filter policy releaseTransientIdToAnyone is active for principal
myuser
15:27:49.965 - DEBUG
[edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:163]
- Processing permit value rule for attribute transientId for principal
myuser
15:27:49.965 - DEBUG
[edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:109]
- Attribute uid has 1 values after filtering
15:27:49.965 - DEBUG
[edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:109]
- Attribute email has 1 values after filtering
15:27:49.965 - DEBUG
[edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:109]
- Attribute telephoneNumber has 1 values after filtering
15:27:49.965 - DEBUG
[edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:109]
- Attribute HexGUID has 1 values after filtering
15:27:49.965 - DEBUG
[edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:109]
- Attribute transientId has 1 values after filtering
15:27:49.965 - DEBUG
[edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:109]
- Attribute surname has 1 values after filtering
15:27:49.965 - DEBUG
[edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:109]
- Attribute givenName has 1 values after filtering
15:27:49.965 - DEBUG
[edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:114]
- Filtered attributes for principal myuser. The following attributes
remain: [uid, email, telephoneNumber, HexGUID, transientId, surname,
givenName]
15:27:49.985 - DEBUG
[edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2ProfileHandler:499]
- Creating attribute statement in response to SAML request
'_192837412983471298347129847' from relying party
'https://www.mydomain.com/shibboleth'
15:27:49.995 - DEBUG
[edu.internet2.middleware.shibboleth.common.attribute.provider.ShibbolethSAML2AttributeAuthority:215]
- Encoded attribute uid with encoder of type
edu.internet2.middleware.shibboleth.common.attribute.encoding.provider.SAML2ScopedStringAttributeEncoder
15:27:49.995 - DEBUG
[edu.internet2.middleware.shibboleth.common.attribute.provider.ShibbolethSAML2AttributeAuthority:215]
- Encoded attribute email with encoder of type
edu.internet2.middleware.shibboleth.common.attribute.encoding.provider.SAML2StringAttributeEncoder
15:27:49.995 - DEBUG
[edu.internet2.middleware.shibboleth.common.attribute.provider.ShibbolethSAML2AttributeAuthority:215]
- Encoded attribute telephoneNumber with encoder of type
edu.internet2.middleware.shibboleth.common.attribute.encoding.provider.SAML2StringAttributeEncoder
15:27:49.995 - DEBUG
[edu.internet2.middleware.shibboleth.common.attribute.provider.ShibbolethSAML2AttributeAuthority:215]
- Encoded attribute HexGUID with encoder of type
edu.internet2.middleware.shibboleth.common.attribute.encoding.provider.SAML2StringAttributeEncoder
15:27:49.995 - DEBUG
[edu.internet2.middleware.shibboleth.common.attribute.provider.ShibbolethSAML2AttributeAuthority:226]
- Attribute transientId was not encoded because no
SAML2AttributeEncoder was attached to it.
15:27:49.995 - DEBUG
[edu.internet2.middleware.shibboleth.common.attribute.provider.ShibbolethSAML2AttributeAuthority:215]
- Encoded attribute surname with encoder of type
edu.internet2.middleware.shibboleth.common.attribute.encoding.provider.SAML2StringAttributeEncoder
15:27:49.995 - DEBUG
[edu.internet2.middleware.shibboleth.common.attribute.provider.ShibbolethSAML2AttributeAuthority:215]
- Encoded attribute givenName with encoder of type
edu.internet2.middleware.shibboleth.common.attribute.encoding.provider.SAML2StringAttributeEncoder
15:27:50.005 - DEBUG
[edu.internet2.middleware.shibboleth.idp.profile.AbstractSAMLProfileHandler:509]
- Filtering out potential name identifier attributes which can not be
encoded by edu.internet2.middleware.shibboleth.common.attribute.encoding.SAML2NameIDEncoder

--

Thanks,

Dan McLaughlin
--
To unsubscribe from this list send an email to users-un...@shibboleth.net

[Dan McLaughlin]

I found a typo in my example below (this typo is NOT in our config
files), here is what our AttributeDefinition looks like, so ignore the
one from earlier...

<resolver:AttributeDefinition id="MyStaticAttribute" xsi:type="ad:Simple"

sourceAttributeID="MyStaticAttribute"> <resolver:Dependency
ref="MYSTATICDC" />
<resolver:AttributeEncoder xsi:type="enc:SAML2String"
name="MyStaticAttribute" friendlyName="MyStaticAttribute" />
</resolver:AttributeDefinition>

--

Thanks,

Dan McLaughlin

On Wed, Nov 2, 2011 at 4:22 PM, Dan McLaughlin
<dmcla...@tech-consortium.com> wrote:
>   <resolver:AttributeDefinition id="AgencyID" xsi:type="ad:Simple"
> sourceAttributeID="MyStaticAttribute">    <resolver:Dependency
> ref="MYSTATICDC" />
>     <resolver:AttributeEncoder xsi:type="enc:SAML2String"
> name="MyStaticAttribute" friendlyName="MyStaticAttribute" />
> </resolver:AttributeDefinition>

[Chad La Joie]

I'm not sure what happens if you tell an attribute definition that the
attribute it is producing is its source. I would guess that is the
issue.

--
Chad La Joie
www.itumi.biz
trusted identities, delivered

[Dan McLaughlin]

Remember nothing has changed in the way we release static attributes,
if I copy the config files back to 2.3.3 everything works.

BTW... I'm not sure what you mean by "tell an attribute definition
that the attribute it is producing is its source", but I'm sure if I
think about it some more it will come to me. ;)

--

Thanks,

Dan McLaughlin

[Chad La Joie]

On Wed, Nov 2, 2011 at 18:01, Dan McLaughlin
<dmcla...@tech-consortium.com> wrote:
> Remember nothing has changed in the way we release static attributes,
> if I copy the config files back to 2.3.3 everything works.

Well, the static attribute definition since Feb 2010 and the simple
attribute definition hasn't changed since Dec 2007.

> BTW... I'm not sure what you mean by "tell an attribute definition
> that the attribute it is producing is its source", but I'm sure if I
> think about it some more it will come to me. ;)

Attribute definitions create IdP attributes with an ID that matches
the ID of the attribute definition. So your attribute definition says
"Create an attribute whose ID is 'MyStaticAttribute' and use the
values of the attribute called 'MyStaticAttribute' as the source of
values for this new attribute.". I have no idea what that will do.
Probably give you an attribute with no values.

[Chad La Joie]

On Wed, Nov 2, 2011 at 19:14, Chad La Joie <laj...@itumi.biz> wrote:
> On Wed, Nov 2, 2011 at 18:01, Dan McLaughlin
> <dmcla...@tech-consortium.com> wrote:
>> Remember nothing has changed in the way we release static attributes,
>> if I copy the config files back to 2.3.3 everything works.
>
> Well, the static attribute definition since Feb 2010 and the simple
> attribute definition hasn't changed since Dec 2007.

sorry, that should have been "... hasn't been changed since Feb 2010".

[Dan McLaughlin]

Up until 2.3.4 this configuration has aways returned the value of the
of the attribute as defined in the data connector, in this case
MyStaticAttribute would be released with the value 1234. We have
several other static attributes defined the same why and they've
always worked. We will do some tests where we change the DC attribute
ID and source ID to have "dc" at the end and see if it helps.

Seeing as how we haven't changed the way our static attributes ID's
and DC attribute ID's have been defined since 2.1.5, this would seem
to be a regression since previous to 2.3.4 the IdP never had any
issues.

We have a test config we are working on over the next couple days, so
we should be able to attach with a debugger and see where things are
going wrong. Do you have any pointers as to where we might want to
set our first breakpoint to see what's happening?

--

Thanks,

Dan McLaughlin

[Chad La Joie]

On Wed, Nov 2, 2011 at 20:38, Dan McLaughlin
<dmcla...@tech-consortium.com> wrote:
> Seeing as how we haven't changed the way our static attributes ID's
> and DC attribute ID's have been defined since 2.1.5, this would seem
> to be a regression since previous to 2.3.4 the IdP never had any
> issues.

It's possible, but I can tell you that my pre-release tests uses a
number of static data connectors and simple attribute definitions and
I didn't have any issues.

> We have a test config we are working on over the next couple days, so
> we should be able to attach with a debugger and see where things are
> going wrong.  Do you have any pointers as to where we might want to
> set our first breakpoint to see what's happening?

It's hard to say. I'd check first whether, when attribute resolution
completed you had the values you thought you did. If not, than it's
somewhere in the resolution process, if so the issue is somewhere in
the filtering.

[Dan McLaughlin]

> It's possible, but I can tell you that my pre-release tests uses a> number of static data connectors and simple attribute definitions and> I didn't have any issues.

So I get that the static data connectors and simple attribute
definitions work in 2.3.4 if the ID's don't match (I haven't confirmed
this myself yet, but we will in the coming days), but do your tests
cover the case where the static data connectors and simple attribute
definition ID's are the same?

Don't get me wrong, I'm not saying that it makes since to have the
ID's the same. I'm just saying it worked when they were the same
prior to 2.3.4, and now it seems to be broken.

We had to drop back to 2.3.3 for now, but I should have some cycles to
confirm the problem by the end of the week. I'll open a bug report
when we are able to confirm the problem in our lab environment.

--

Thanks,

Dan McLaughlin

[Chad La Joie]

On Wed, Nov 2, 2011 at 21:05, Dan McLaughlin
<dmcla...@tech-consortium.com> wrote:
>> It's possible, but I can tell you that my pre-release tests uses a> number of static data connectors and simple attribute definitions and> I didn't have any issues.
>
> So I get that the static data connectors and simple attribute
> definitions work in 2.3.4 if the ID's don't match (I haven't confirmed
> this myself yet, but we will in the coming days), but do your tests
> cover the case where the static data connectors and simple attribute
> definition ID's are the same?

No.

> Don't get me wrong, I'm not saying that it makes since to have the
> ID's the same.  I'm just saying it worked when they were the same
> prior to 2.3.4, and now it seems to be broken.

I'm not saying it didn't work, but I certainly never intended for that
sort of cyclic dependency to do anything meaningful. If I had
considered it, I would have made it simply throw an exception at start
up like the other cycles that are checked for.