Trouble with configuration reloads

Ilkka Lindblom don at idiosynkrasia.net
Mon May 16 20:55:17 UTC 2022


Hello

I ran into an issue with IdP 4.1.4, old version, but thought I would 
document it for the benefit of others maybe running into the same log 
message.

My task was to add another scripted attribute definition. I did, 
basically taking reference from the existing, working scripted 
attributes. Then I reloaded resolver and filter services, as usually 
when I change attribute configuration on this IdP. I found my attribute 
was never added to SAML responses, despite logs suggesting it was processed.

After figuring my script was working, and actually simplifying it down 
to this (reconstructed from memory, apologies for errors):

<AttributeDefinition xsi:type="ScriptedAttribute" id="TestScript">
   <AttributeEncoder xsi:type="SAML2String" name="TestAttribute" />
   <Script>
     <![CDATA[
       TestScript.getValues().add("TestValue");
     ]]>
   </Script>
</AttributeDefinition>

... I resorted to enabling debug logs, and found these messages:

2022-05-16 15:33:57,122 - DEBUG 
[net.shibboleth.idp.saml.saml2.profile.impl.AddAttributeStatementToAssertion:184] 
- Profile Action AddAttributeStatementToAssertion: Attempting to encode 
attribute TestScript as a SAML 2 Attribute
2022-05-16 15:33:57,122 - DEBUG 
[net.shibboleth.idp.saml.profile.impl.BaseAddAttributeStatementToAssertion:321] 
- Profile Action AddAttributeStatementToAssertion: Attribute TestScript 
does not have any transcoding rules, nothing to do
2022-05-16 15:33:57,122 - DEBUG 
[net.shibboleth.idp.saml.saml2.profile.impl.AddAttributeStatementToAssertion:188] 
- Profile Action AddAttributeStatementToAssertion: Attribute TestScript 
did not have SAML 2 Attribute transcoder instructions associated, 
nothing to do

There are very few results on Google for these errors. After some 
frustrating hours I got the idea - maybe the config reload is not 
enough? So I arranged to restart the IdP, and then the attribute of 
course did work. I don't know if this is expected behavior but there it 
is. So, if you get this problem, and your AttributeEncoder seems to be 
in place, try to stop and start the IdP.

Br,
Ilkka Lindblom


More information about the users mailing list