attribute resolver/filter reload weirdness (bug?)

Paul B. Henson henson at cpp.edu
Wed Jan 12 05:40:28 UTC 2022


So I was asked to set up SAML for our Trend Micro deep security admin
console; it was fairly straightforward other than using goofy attributes,
which I defined as:

+    <!-- Trend micro admin console "special" attributes -->
+
+    <AttributeDefinition xsi:type="Simple" id="trend_username">
+        <InputDataConnector ref="LDAP" attributeNames="uid" />
+        <AttributeEncoder xsi:type="SAML2String"
+                         friendlyName="RoleSessionName"
+                         name="https://deepsecurity.trendmicro.com/SAML/Attributes/RoleSessionName"/>
+    </AttributeDefinition>
+
+    <AttributeDefinition xsi:type="Mapped" id="trend_role">
+        <InputDataConnector ref="LDAP" attributeNames="memberOf" />
+        <AttributeEncoder xsi:type="SAML2String"
+                         friendlyName="RoleEntitlement"
+                         name="https://deepsecurity.trendmicro.com/SAML/Attributes/Role"/>
+        <ValueMap>
+            <ReturnValue>urn:tmds:identity::0:saml-provider/CPP-IDP,urn:tmds:identity::0:role/Full</ReturnValue>
+            <SourceValue>uid=nt-mgr,ou=group,dc=cpp,dc=edu</SourceValue>
+        </ValueMap>
+        <ValueMap>
+            <ReturnValue>urn:tmds:identity::0:saml-provider/CPP-IDP,urn:tmds:identity::0:role/View</ReturnValue>
+            <SourceValue>uid=itip_cloud_staff,ou=group,dc=cpp,dc=edu</SourceValue>
+        </ValueMap>
+    </AttributeDefinition>

I also added a filter policy for them:

+  <AttributeFilterPolicy id="trend_admin_console">
+    <PolicyRequirementRule xsi:type="Requester" value="https://itdsm01.ad.cpp.edu:4119/saml" />
+
+    <AttributeRule permitAny="true" attributeID="trend_username" />
+    <AttributeRule permitAny="true" attributeID="trend_role" />
+  </AttributeFilterPolicy>

I deployed the config, and went to test it, and it didn't work. The app
complained it wasn't getting attributes. I looked at the logs, and it
showed they were included:

2022-01-11 21:25:22,037 - 10.104.223.234|2022-01-12T05:25:21.452540Z|2022-01-12T05:25:22.037418Z|henson|https://itdsm01.ad.cpp.edu:4119/saml|_6ed32a12f3674c84df79752ff6968973|password|2022-01-12T05:05:39.435Z|trend_role,trend_username|AAhzZWNyZXQ2M7Pc3N1ZeCh+SDAGYSVQbBn3rYZBxG2LlnRJv44bxk4ePlT/G5wc2P5Y9x6h67eKC9BWMTbuhvUTnUZewDVeSk1L5MHh3N5c75kdUkpKY6Cz0Tst319OGO6o9SbKCn0H/8DQGfZBieLsnw==|transient|true|false||Unsolicited|POST||Success||211e0d496cb95b81d101385ba05bb02126aeb1f786f522d0caacda30e8571d54|Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0 - [10.104.223.234/node0xkdupzr2jwfmty2f2h8iylkz409928]

However, on the wire they just weren't there in the assertion. I confirmed
the config had been reloaded when the updated file were deployed:

2022-01-11 21:24:51,816 - 127.0.0.1/node017jxahd0jso99oyj0h3lerozh410104 - INFO [net.shibboleth.util
ities.java.support.service.AbstractReloadableService:259] - Service 'shibboleth.AttributeResolverSer
vice': Reloading service configuration
2022-01-11 21:24:52,464 - 127.0.0.1/node017jxahd0jso99oyj0h3lerozh410104 - INFO [net.shibboleth.ext.
spring.service.ReloadableSpringService:421] - Service 'shibboleth.AttributeResolverService': Complet
ed reload and swapped in latest configuration for service 'shibboleth.AttributeResolverService'
2022-01-11 21:24:52,467 - 127.0.0.1/node017jxahd0jso99oyj0h3lerozh410104 - INFO [net.shibboleth.ext.
spring.service.ReloadableSpringService:428] - Service 'shibboleth.AttributeResolverService': Reload 
complete
2022-01-11 21:24:52,771 - 127.0.0.1/node01wkfo1l4yk4egvabpjsymuy2o410106 - INFO [net.shibboleth.util
ities.java.support.service.AbstractReloadableService:259] - Service 'shibboleth.AttributeFilterServi
ce': Reloading service configuration
2022-01-11 21:24:52,995 - 127.0.0.1/node01wkfo1l4yk4egvabpjsymuy2o410106 - INFO [net.shibboleth.ext.
spring.service.ReloadableSpringService:421] - Service 'shibboleth.AttributeFilterService': Completed
 reload and swapped in latest configuration for service 'shibboleth.AttributeFilterService'
2022-01-11 21:24:52,996 - 127.0.0.1/node01wkfo1l4yk4egvabpjsymuy2o410106 - INFO [net.shibboleth.ext.
spring.service.ReloadableSpringService:428] - Service 'shibboleth.AttributeFilterService': Reload co
mplete

I then restarted jetty, and after coming back up, it worked fine, and the
attributes were included. The audit entry looked about the same:

2022-01-11 21:26:04,525 - 10.104.223.234|2022-01-12T05:26:03.772998Z|2022-01-12T05:26:04.524987Z|henson|https://itdsm01.ad.cpp.edu:4119/saml|_7ae3b69431546041558cb462b82f59c8|password|2022-01-12T05:05:39.435Z|trend_role,trend_username|AAhzZWNyZXQ2M0A6NDC+UsYE4H/sTmbBxsyWo9z9gVUjkklcSBBn/0H2ErDh51oAHsgmKi4BWUzYB5TRGWUz/TZJJxzj3Ce1DHSHklGi943nw38ix4l1k9mzycoQAWuLnKhaHH0qFrnRMH7bRak1RS1OmA==|transient|true|false||Unsolicited|POST||Success||211e0d496cb95b81d101385ba05bb02126aeb1f786f522d0caacda30e8571d54|Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0 - [10.104.223.234/node01j3tn1gd61fzs4x07z9pl8xma8]

This was weird. I don't usually have any issues reloading the attribute
resolver or filter configs dynamically. Was there anything particular
about these config changes that would have required a restart rather than
a reload?

Hmm, I had already restarted all my prod servers, but I went back to a dev
server and reloaded the log config to debug wihout restarting. It had this
to say:

2022-01-11 21:37:05,998 - 10.104.223.234/node01fu5qy1xkv29m139xm5sg8ejwe251164 - DEBUG [net.shibbole
th.idp.saml.saml2.profile.impl.AddAttributeStatementToAssertion:184] - Profile Action AddAttributeSt
atementToAssertion: Attempting to encode attribute trend_role as a SAML 2 Attribute
2022-01-11 21:37:05,998 - 10.104.223.234/node01fu5qy1xkv29m139xm5sg8ejwe251164 - DEBUG [net.shibbole
th.idp.saml.profile.impl.BaseAddAttributeStatementToAssertion:321] - Profile Action AddAttributeStat
ementToAssertion: Attribute trend_role does not have any transcoding rules, nothing to do
2022-01-11 21:37:05,998 - 10.104.223.234/node01fu5qy1xkv29m139xm5sg8ejwe251164 - DEBUG [net.shibbole
th.idp.saml.saml2.profile.impl.AddAttributeStatementToAssertion:188] - Profile Action AddAttributeSt
atementToAssertion: Attribute trend_role did not have SAML 2 Attribute transcoder instructions assoc
iated, nothing to do
2022-01-11 21:37:05,998 - 10.104.223.234/node01fu5qy1xkv29m139xm5sg8ejwe251164 - DEBUG [net.shibbole
th.idp.saml.saml2.profile.impl.AddAttributeStatementToAssertion:184] - Profile Action AddAttributeSt
atementToAssertion: Attempting to encode attribute trend_username as a SAML 2 Attribute
2022-01-11 21:37:05,998 - 10.104.223.234/node01fu5qy1xkv29m139xm5sg8ejwe251164 - DEBUG [net.shibbole
th.idp.saml.profile.impl.BaseAddAttributeStatementToAssertion:321] - Profile Action AddAttributeStat
ementToAssertion: Attribute trend_username does not have any transcoding rules, nothing to do
2022-01-11 21:37:05,999 - 10.104.223.234/node01fu5qy1xkv29m139xm5sg8ejwe251164 - DEBUG [net.shibbole
th.idp.saml.saml2.profile.impl.AddAttributeStatementToAssertion:188] - Profile Action AddAttributeSt
atementToAssertion: Attribute trend_username did not have SAML 2 Attribute transcoder instructions a
ssociated, nothing to do

This seems like a bug? Unless I screwed up the config? In a way that works
fine with a restart but not a reload 8-/?

Thanks...

-- 
Paul B. Henson  |  (909) 979-6361  |  http://www.cpp.edu/~henson/
Operating Systems and Network Analyst  |  henson at cpp.edu
California State Polytechnic University  |  Pomona CA 91768


More information about the users mailing list