Shibboleth Developer's Meeting, April 19, 2013

Attendees: Tom, Scott, Brent, Ian, Daniel, Marvin, Paul

Call Administrivia

Next call is next Friday.

60 to 90 minute call window.

Brent

V2 Security Advisory. Getting back to V3.

Brent : Was enthusiastic about using Spring in a normal way, HttpServletRequest/Response injection could make other things easier. Looking for feedback on whether we go down the road of Spring injection of HttpServletRequest/Response rather than storing in the ProfileRequestContext. Based on OperationContext, with slots for request and response. Chad did this maybe for Web Flow integration. Maybe for MessageHandlers or ProfileActions only, wire via Spring ?

Scott: Need to use threadlocal ?

Brent : Yes. Three ways (1) MVC RequestDispatcherServlet, (2) non-MVC RequestContextListener, (3) older Servlets use a Filter. Maybe need to wire bean in as a proxy rather than FactoryBean. However, Web Flow has multiple requests and responses, so a proxy might work better vs a FactoryBean because.

Scott : Thought it worked if we use prototype scoped beans.

Brent : Unclear on the bean life cycle in Webflow.  FactoryBean might work.

Scott : Actions get created when flow is about to run the action. The flow requests the bean. The FlowExecutor does this.

Brent/Scott : Proxy model is probably cleaner.

Scott: Layer above Web Flow knows about requests/responses, from ExternalContext. Whatever setting up ProfileRequestContext needs to do the request response setup, but does not make sense.

Brent: Was skeptical. Requests/responses unpacked on every action. Floating idea, needs testing.

Scott: Action properties vs relying-party notion ? Lots of relying-party configuration machinery not wired up yet influences behavior in action components. Action properties will be helpful especially with statefulness.

Brent: Collaborator components should be wired with Spring. Runtime state needs to be transferred in Context. Gray area ... requests and responses are kinda gray, since they are known to Spring container. Maybe are a 3rd distinct type. Maybe we should use injection as collaborators.

Scott: Maybe have to use advanced Spring features, method injection.

Daniel: Requests and responses seem like runtime, Spring should do as much heavy lifting as possible.

Scott: Threadlocal...

Brent: Threadlocals can be dangerous if used improperly. Especially if buried in an undocumented library. But ok if used carefully and consciously.

Scott: Threadlocals have flavor of global variables.

Daniel: Servlet v3 spec container ?

Brent: Async request processing...explicitly invoked.

Scott: Decouples thread pool handling of Servlet request from incoming client connection. From 1:1 to 1:many.

Marvin: Threadlocals are limited in v3 spec support.

Tom: Lots of changes ? performance issues ?

Marvin: Has preliminary data that Web Flow may have performance penalty.

Scott: Feel good that we can replace Web Flow if we need to.

Brent: True. Attractiveness of Webflow was: 1) Built-in conversation support 2) people's existing familiarity with it, books, documentation for it, etc.

Scott: Subflow is attractive. Conversation state will need to be overriden, so we might lose benefits of using built-in mechanism. Like to use Web Flow but it could be swapped out.

Brent: Performance issues...application performance monitoring on a running idp ? http://www.appdynamics.com  http://newrelic.com (has free version) These products instrument the jvm, and produce dashboards and reporting. Not too invasive, 2-3% overhead.

Daniel: Yourkit. But impacts performance significantly. 

Scott/Daniel: Have test environments.

Tom: Next ?

Scott: Inject entire context into Actions ? What is overhead and benefit ratio of declarative injection in spring configuration files ? Maybe adaptor can relieve configuration verbosity.

Brent: Spring can do auto-wiring based on type. Plus annotations makes life really easy.

Marvin: Generic auto-wiring capability, some JSR, for annotation based configuration.

Brent: Not really suggesting annotations for the IdP, just auto-wiring via XML config.

Scott: Want auto-wiring of boilerplate.

Daniel

RdbmsDataConnectorBeanDefinitionParser supporting Spring IOC config and the v2 schema.

Daniel: Pinged Chad regarding caching, waiting for response. Still not sure why moved from ehcache to guava.

Daniel: Tinkering with wiring of pooling implementations.

Daniel: Need to review Rod's commit.

Ian

XmlSecTool 1.2.0 released, huzzah!

That's probably about it for this month.

Ian: In production in UKf.

Marvin

Engaged Scott on dev list when Webflow topics come up. Next week I hope to rework some of the CAS protocol flow actions with the new AbstractProfileAction components.

Rod - Apologies

• Held up by illness.
• All parsers for AttributeDefinitions have been checked in.
• Some work needed wrt to eventual loosening of the schema needed
• ValueMapping definition still outstanding, needs some design, expected this week.
• I will circulate a proposal about class names for the parsers and tests.
• Next week.  Finish parsers for Attribute definitions.  Move on to the Static, computed, and Stored Data Connectors, thence back to filters.

Scott

2.4.0 release uneventful apart from a few POM mistakes. Not much feedback so far, still have some feature documentation to complete. Noted one or two more things I would have cleaned up, but nothing big.

Updated ant-extensions back to parent-v3, don't know if that will be used. Presumption is any more patches for V2 will just use the 1.0.0 version I pushed.

Tested use of prototype beans in web flow actions successfully, proposed an execution model for our actions based on AbstractAction class in SWF. Error handling being dicussed on list.

Q: Do we need to trap all exceptions we want to use for signaling SWF transitions? Seems like we do. Suggest we adopt automated translation of exception class name into event ID (think Tom proposed this already at some point).

Q: Currently using absence of EventContext to signal "proceed" from OpenSAML actions. Less code but probably not so nice for explicitness, change back to explicit EventContext?

Discussing relationship between actions, handlers, decoders/encoders with Brent on list. Agree that with current breakdown we'll be migrating some actions into handlers. Can work on building action wrappers we need for some of this.

Will spend today sketching out ideas for context objects to use for some of the important system components like authentication and sessions so Brent and I can review next week.

Scott: Playing with coding of stateful beans. Looking at (1) Spring Web Flow does not handle exceptions as transition points ?

Marvin: Yes, an onException clause can be added.

Scott: Should systematically map Exceptions into Events...could automate by catching exceptions and morph into Events. Less comfortable with RuntimeException handling, could be done similarly, if we want to. Probably a premature optimization to implicitly return "proceed". Will go undo.

Scott: Talking with Brent, already not totally happy with ProfileRequestContext as a baked in context, will talk with Brent next week. We do have some ProfileActions that will become MessageHandlers, need a consistent execution model,  pre|postExec consistency. If we have MessageHandlers, we will need Actions to wrap them.

Scott: Will spend time thinking about context tree for authn etc., talk with Brent.

Tom: I2 ?

Scott: Board meeting will be open for first hour at 2.

Paul

Still seeing session bug with one particular clustered customer, 2x or 100x per day.

Tom

Worked through some installation, configuration, and upgrade ideas.

Topics

Decisions

Guava Optional vs @null

Tom AI : look at second Storage API try.

Scott: Leaning to @null. Didn't see lots of support for Optional. Consider multiple methods vs Optional parameters.

Coding convention : getLdapUrl or getLDAPURL

Tabled for further discussion.