debugging expiring password intercept
Paul B. Henson
henson at cpp.edu
Thu Jun 1 23:10:38 EDT 2017
I'm testing my 3.3 upgrade, and the expiring password intercept doesn't
seem to be working. I'm not sure what I missed. We store the password
expiration date in our LDAP directory in unix time_t format, and I've
defined a scripted attribute that converts it into a format that the
joda java class can deal with:
<AttributeDefinition xsi:type="ScriptedAttribute" id="shibPasswordExpiration">
<Dependency ref="LDAP" />
<Script>
<![CDATA[
if (typeof cppEduPersonPwdExpiration != "undefined") {
var dateString =
(new Date(cppEduPersonPwdExpiration.getValues().get(0)*1000)).toLocaleString();
dateString = dateString.substring(0, dateString.length()-15);
shibPasswordExpiration.addValue(dateString);
}
]]>
</Script>
</AttributeDefinition>
and I've configured the setup in expiring-password-intercept-config.xml:
<bean id="shibboleth.expiring-password.Condition" class="net.shibboleth.idp.profile.logic.DateAttributePredicate"
c:attribute="shibPasswordExpiration" p:resultIfMissing="true">
<constructor-arg name="formatter">
<bean class="org.joda.time.format.DateTimeFormat" factory-method="forPattern" c:_0="E M d y H:m:s" />
</constructor-arg>
<property name="systemTimeOffset">
<bean class="org.joda.time.Duration" factory-method="standardDays" c:_0="-7" />
</property>
</bean>
However, when I log in with a test user whose password is set to expire in
4 days, nothing happens. I turned on debugging, and verified the scripted
attribute is getting set:
2017-06-01 19:48:00,836 - DEBUG [net.shibboleth.idp.attribute.resolver.AbstractAttributeDefinition:247] - Attribute Definition 'shibPasswordExpiration': produced an attribute with the following values [StringAttributeValue{value=Mon Jun 05 2017 23:59:00}]
Looking for relevant stuff in the logs, I see:
2017-06-01 19:43:56,584 - DEBUG [net.shibboleth.idp.profile.spring.factory.FlowDefinitionRegistryFactoryBean:240] - Registered flow ID 'intercept/expiring-password' using 'file [/opt/shibboleth-idp/flows/../system/flows/intercept/expiring-password-flow.xml]'
but that's the only mention of the flow in the whole log, I don't see any
reference to it during the time of the actual authentication. I am testing
with CAS right now, not SAML, but I would think the intercept would work for
both?
I only enabled DEBUG for idp.loglevel.idp, is there another category I
should crank too? Any other thoughts on what I might have misconfigured?
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