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