Scriptable DataSealerKeyStrategy Question

[Snyder, Bill]

I ended up going with the custom java class solution and it appears that things are working (at least to some degree).  To be clear, I've created a class that implements the DataSealerKeyStrategy interface as defined here:

http://git.shibboleth.net/view/?p=java-support.git;a=blob_plain;f=src/main/java/net/shibboleth/utilities/java/support/security/DataSealerKeyStrategy.java;hb=HEAD

I'm trying to test it thoroughly and could use some help understanding the lifecycle of cookies signed with the sealer key.  To test the IdP, I'm using the shibboleth SP and an LDAP identity store like I2 has published here:

https://github.internet2.edu/docker/shib-idp/blob/master/test-compose/

In order to make manual testing reasonable, I've gone ahead and tweaked the SP's session timeout to 15 seconds as is documented here:

https://wiki.shibboleth.net/confluence/display/SP3/Sessions

The behavior I see is that I can successfully get logged in at the IdP and redirected back to the SP.  If I keep refreshing the SP page inside of the 15 second timeout window, the page keeps reloading properly and no calls to the IdP are made.  This is the behavior I would expect.

If I let the page sit for longer than the 15 second timeout, the browser gets redirected back to the IdP which appears to successfully redirect the user back to the SP without requiring them to login again.  What is confusing me is that, in this situation, I would expect there to be a call to my class's implementation of the getKey() method, passing in the version id of the sealer key previously used, but the calls that are made are to the getDefaultKey() method.   Is this the expected behavior?

If I let things sit for a while (maybe hours), I will see calls to the getKey() method be made but, in this scenario, the user seems to always get redirected back to the login screen.  My goal is to be able to definitively test that I can keep X number of sealer key versions and have those sessions still work and also verify that once a sealer key version is "rotated out", that any sessions using that sealer key will be terminated.

I think I could use some help understanding how the sealer key lifecycle works and what timeout parameters (beyond the one mentioned above) I might play with to make testing this easier.  I could also use some help understanding when the getKey() and getDefaultKey() methods should be getting called.

Thanks,
Bill

On 10/17/19, 11:38 AM, "dev on behalf of Cantor, Scott" <dev-bounces at shibboleth.net on behalf of cantor.2 at osu.edu> wrote:

    On 10/17/19, 1:18 PM, "dev on behalf of Snyder, Bill" <dev-bounces at shibboleth.net on behalf of bpsnyder at amazon.com> wrote:
    
    > If I include the p:updateInterval attribute on the bean, I get the following exception during servlet initialization:
    
    The old code can't handle the newer Duration types. We probably used longs before with a @Duration annotation we defined to handle the conversions. I didn't consider that but it's a consequence of the backport.
     
    > While I'm certainly open to trying more things or other scripting engines, I fear that the flexibility/extensibility that
    > the scripting based solution is intending to provide is actually making things more difficult for anything but the
    > simplest use cases.  These issues, coupled with the fact that we still need to define our own bean inside of the global-> system.xml file, lead me to believe that writing a custom java class that implements DataSealerKeyStrategy is much
    > simpler and more straight forward.  If anyone has any thoughts of suggestion, I'm all ears.
    
    If Jython's that broken that's definitely disappointing. I don't think anything related to node.js is relevant, but that doesn't mean there are workarounds there either. Nashorn is awful, and I tend to use Rhino, but I don't think it would make much difference. I only know how to reference Java code from them, not other javascript. I would definitely think that has to be embedded inline to work.
    
    Java's fine, but that just means it will be a third party extension jar (and whatever other jars are needed) to add to the system. What people choose to add to their local deploys is not a concern of ours as long as they understand any conflicts introduced aren't things we can necessarily resolve.
    
    In any case, that API is the same, AFAIK, between V3 and V4. There are issues such as the Duration thing that will be internal to the plugin, so I doubt it will be a final end state to have the same code working with both, but the changes would be pretty minor.
    
    -- Scott
    
    
    -- 
    To unsubscribe from this list send an email to dev-unsubscribe at shibboleth.net