Shibboleth Developer's Meeting, August 9, 2013
Attendees: Brent, Daniel, Ian, Mike (CMU), Marvin, Paul, Rod, Scott, Tom
Dial-in attendee identification.
Next call is next Friday. Any reason not to meet ?
60 to 90 minute call window.
Have started working on refactoring of metadata support to MetadataResolver API. Will likely have a couple of questions/issues to discuss on the list.
Nothing to report.
Nothing to report.
- Did the schema validation thing.
- Did the spring bean config for the attribute mapper
- Rest of the week spent in a cleanup pass over attibute-filter for Tom.
- Next up:
- Cleanup pass on Attribute Resolver
- Auto generate Attribute mapper config
- Topical bug fixing
- TOU/Attribute release.
- Resources - us vs spring vs ??
- More attribute filter documentation?
Attempted aborted wiki upgrade, ran into significant issues. Identified one possible problem with the plugin manager that was corrected, will need to go back and start testing from scratch on VM.
Rest of time was spent on the "end" stages of the authentication flow:
- adding custom information to Java Subject
- canoncializing Subject into principal name string
- detecting an identity switch between active session and a new result
- creating the SubjectContext as the output of the process
With more pieces done, seams are showing and need to work more on error handling/tracking, and how the flow would control which type of custom Principal would be added to the Subject. For example, a flow allowing password and MFA at the same time via one UI needs to know how to decide which actions to run, and what custom AuthenticationContextClassRef to attach.
Considering how best to integrate SubjectCanonicalizer notion into existing use cases like PrincipalConnector in V2.
The primary task on my mind is performance testing. I currently do not have any sort of harness set up to examine Web Flow, and I think I should. An example would be to try and measure if there is a discernible impact on performance or cpu for stateless vs stateful action beans. My hypothesis is that I will not be able to discern much difference, but the test harness itself would be worthwhile, to me.
Before performance testing, I wanted to get Velocity figured out, and although there are issues to resolve, I think we'll be okay. As a recap, on the last call and on the dev list it became clear to me that Velocity will not replace our ResourceFilter, but rather we would provide a VelocityResourceFilter. One issue I can think of is bootstrapping Velocity to parse our configuration files via the ResourceFilter API, I imagine that instance of Velocity will be spun up and spun down just for that purpose. Consequently, I assume that we will probably want to externalize the Velocity configuration.
Another comment about Resources is that I would like to understand why the HttpResource should be replaced. If someone else gets to it, please summarize for me, that would be nice.
I think I should create the idp-attribute-mapper-api|impl modules and move over Rod's work there, I think we have agreement on that.
I should create a JIRA issue for the default permit any <AttributeRule /> "feature", see if there is any traction, but slate for 3.x, meaning it does not have to be done for 3.0 if we do it at all.
Git. I think it would be good to have a summary, perhaps on the wiki, of our current stance.
Bikeshedding. Disclaimer : I actually have a bike shed and it needs to be painted, white vs barn-red, not sure. I purposefully bikeshed-ed regarding getLdapUrl vs getLDAPURL, because it was interesting, but I do want to spend our time wisely.
These calls. I have tried to minimize my "lead"ness on these calls because I actually feel like I do a pretty horrible job of it, so constructive feedback is appreciated, and I am totally open to changing things.
AI : Work with Brent on moving shib-testbed to svn.shibboleth.net
AI : Follow up on JIRA regarding schemaLocation, which Scott will create/update
Note : Rod will take point on creating summary issues in JIRA regarding Resources, possible the wiki.