some comments about v3 post-login / post-authn flows

[Tom Zeller]

After last Friday's dev call, I mocked up a "master" post-authn flow,
which calls other post-authn flows as subflows, following Scotts' c14n
model. The configuration exposed to the user contains an ordered list
of subflows, which looks like :

conf/post-authn.xml :

<util:list id="shibboleth.PostAuthnFlows">
   <ref bean="post-authn/consent/terms-of-use" />
   <ref bean="post-authn/consent/attribute-release" />
</util:list>

Where the strings like 'post-authn/consent/terms-of-use' are flow IDs,
and their beans are flow descriptors which can be configured by the
user. This feels alot like Servlet Filters, where subflows might
decide to terminate execution of the chain or continue to the next
subflow.

I wired in the master post-authn subflow into the abstract SSO flow
after attribute resolution :

<subflow-state id="DoAttrCheck" subflow="access/attr-check">
   <input name="calledAsSubflow" value="true" />
   <transition on="proceed" to="DoPostAuthnSubflow" />
</subflow-state>

 <subflow-state id="DoPostAuthnSubflow" subflow="post-authn">
    <input name="calledAsSubflow" value="true" />
    <transition on="proceed" to="BuildResponse" />
</subflow-state>

and was thinking that this could also be wired into the CAS
abstractValidate flow during the resolveAttributes action-state, but
before evaluating extractAttributes.

Given this setup, someone deploying a post authn flow would need to
copy their flow definitions below conf/flows/post-authn/, with
Velocity templates going to views/, etc., without needing to modify
anything under system/.

When developing in Eclipse, it is possible to run the IdP with custom
post-authn flows without copying anything into java-identity-provider
with idp.home set to 'classpath*:' and a custom ResourceLoader which
knows about 'classpath*:' for non-Webflow use :

@Override
public Resource getResource(String location) {
  if (location.startsWith(CLASSPATH_ALL_URL_PREFIX)) {
    return new ClassPathResource(location.substring(CLASSPATH_ALL_URL_PREFIX.length()),
getClassLoader());
  }
  return super.getResource(location);
}

I guess one might consider suggesting a patch to Spring, but modifying
DefaultResourceLoader seems unlikely. And, for Velocity to understand
'classpath*:', the preferFileSystemAccess property needs to be turned
off in the VelocityConfigurer to force usage of Spring's resource
loader rather than Velocity's :

<bean id="shibboleth.VelocityConfig"
class="org.springframework.web.servlet.view.velocity.VelocityConfigurer">
  <property name="resourceLoaderPath" value="%{idp.views:%{idp.home}/views}" />
  <property name="preferFileSystemAccess" value="false" />
  ...
</bean>

Again, the point of all this is to separate the IdP
(java-identity-provider) from post-authn flow "extensions" during
development, and deployment would involve copying stuff to the right
place in idp.home.

I have some generic/abstract/base post-authn flow stub classes, the
context, actions, event IDs, etc., and was going to work on storage
next. I'm not sure where those should live in java-identity-provider,
maybe idp-profile-*, not sure how abstract they will be.

I'm hoping that once a post-authn model/framework is in place, folks
interested in consent flows would know how to plug in to the IdP in a
"standard" way.

I'm probably forgetting something I meant to say, maybe I should have
done a wiki page, but this sketches out how custom flows might be
developed and deployed.