Shib sessions, portal services, and shib-cas-authenticator

[Cantor, Scott]

> It's unclear to me how Shib with shib-cas-authenticator handles sessions,

No authentication plugin has anything directly to do with how the IdP manages sessions, the sessions simply happen to contain, among other things, authentication results, regardless of what produces them.

Session configuration is itself outside authentication and is turned on or off with a property. The plugin could work whether sessions were enabled or not, but the session layer and the IdP SSO logic would bypass use of the plugin when it can.

> Would a fix work that focuses on the Shib session, such as using
> idp.session.defaultSPlifetime in the RP,

That setting is about SP session lifetimes as influences by SAML advisory features, it has nothing to do with IdP session management or behavior. It acts as a global value for a per-relying-party setting controlling the SessionNotOnOrAfter feature in SAML.

The main settings relevant to whether the IdP will invoke the plugin flow and go to CAS are mainly the timeout/lifetime setting of that authentication flow (assuming IdP sessions are enabled).

> If it's possible to make Shib aware of the portal token by configuring the IdP
> to receive, store, and pass it back through shib-cas, we're open to doing 
> that.

With code, I imagine anything is possible but since I don't know anything about what you're talking about with this token or what got hacked into CAS to make it work, I couldn't say.

It feels to me like you should be changing your overall session policies in both layers and dumping this token outright. That's just reinventing cookies and sessions again.

-- Scott