Scribing Template --Thursday, Oct 4, 2012 at 4:30pm -- Salon 3
TOPIC: Shibboleth 3.0: Plans, Architecture, Engagement
CONVENER: Scott Cantor
SCRIBE: Scott Cantor
# of ATTENDEES: ~20
MAIN ISSUES DISCUSSED
Scott presented an overview of the planning process around the V3.0 Shibboleth Identity Provider work, described various aspects of the architecture, asked for feedback on various feature areas, and discussed opportunities for engagement.
Plans
With funding into next year secured, the Consortium Board has asked the developers to propose a development plan into early 2014 based on their perception of what we need to deliver for the project. The team's internal belief is that delivering a viable V3 IdP platform is the most important priority for the project apart from ongoing support and maintenance, and we want to aim for that in the early 2014 window.
Discussions on scope are now taking place so that resources can be estimated.
Some of the system design has been documented by Chad prior to his departure from the project, and it will be fleshed out for public consumption at https://wiki.shibboleth.net/confluence/display/IDP30/Software+Design
The developers' ongoing work plan will be public as well, with initial work on the plan due by the end of October. If we miss delivery, we want to be able to clearly document why.
Archictecture
Scott outlined the key architectural goals for the work:
- Radical decomposition of the code into smaller modules
- Completing the move toward extensibility that made up the attribute resolver and filter modules in the 2.x code base
- Moving to Spring Webflow if possible for as much of the orchestration within the system as possible
- Decomposing the authentication steps to support multi-step workflows, lots of existing customizations, and radically simpler creation of new extensions
- Factoring as many behavioral assumptions as possible such that they're removed into discrete Action objects that can be replaced with new ones by deployers or in future versions
There's a general goal of moving to more frequent major releases rather than favoring API stability, which the project thinks V3 will enable.
It is admittedly a very "design" focused release rather than a release focused on new features which the project believes will enable more rapid delivery of features on an ongoing basis in the future.
We did some deeper dives into some of the specific areas of the system.
Authentication
We brainstormed a number of use cases that were either envisioned as part of planning the extensibility model of the new software, or should be taken into account.
- Multi-factor, particularly independent factors
- Step-up authentication
- Notifications of password expiration
- Coarse-grained authorization by the IdP by refusing to issue responses based on user attributes
- Flexibility in implementing advanced SAML AuthnContext selection logic
- Error handling, such as account lockout or other conditions
- Registration flows (e.g., go here to sign up for an account of some type and then return to login)
It was noted that there are GUI tools people have used to manipulate Spring Web Flows of this kind without programming. Initial creation of these kinds of components will still require Java programming, but the belief is that the work involved and amount of code to write will be much less than now.
Clustering
Scott described the current thinking about clustering support, which is to allow for development of memcache-style approaches, but to focus by default on client-side storage of sessions in cookies. A server would maintain state on a node only during a request/login/response conversation, but not between conversations.
It was noted that even without stickiness in a load balancer, it's possible to accomodate that constraint by having a server that detects an "unstuck" client proxy its requests to the other server to maintain the conversation.
Scott mentioned that moving to a client state model means that any chance of implementing logout has to rely on server state of a kind of "revocation" model where sessions are marked for removal the next time they show up at the IdP. This has downsides, but a big upside is that you can do this without third party cookies if the SP also supports that model.
Consent / Attribute Release
We discussed how features like user consent for data release would be worked into the system. These are just self-contained "action" components that would be injectable into the various flows of the software, and that actions can interact with the user, and add or remove attributes into the request context easily.
The question of how consent decisions would be stored came up, and it was acknowledged that either it becomes per-client, which bothers users, or still has to be persisted somehow. But in practice, a loosely replicated database can be used for that with no real consequence of data loss as long as decisions are also logged for record keeping.
Configuration
A lot of decisions have yet to be made on the configuration formats. Community input on this on the dev list is useful, particularly which parts create the most difficulty for people.
Scott indicated that his personal view is that getting the release out to build on in the hoped for timeframe is more valuable than getting a new configuration model in place at this stage, with a future release taking on that work. New features can be exposed in a backward-compatible way with existing configuration files for the most part.
But authentication, being very differently architected, is probably going to change a lot.
-
ACTIVITIES GOING FORWARD / NEXT STEPS
The main route to technical engagement at this stage is to consider taking some time in the coming months to evaluate your own customizations of V2.x within the V3.x architecture to help the team validate its design work.
Also consider working on updating those extensions or creating any that you've been planning using the new code in 2013 so that the product will meet those needs and have some useful feature additions available with its release.
-