Shibboleth Developer's Meeting, November 01, 2013

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

Call Administrivia

Dial-in attendee identification.

Next call is next Friday. Any reason not to meet ?

60 to 90 minute call window.

Brent

Daniel

Ian

Rod

• Generic types - ongoing (don't ask)
• Interfaces from Base - under way.  Some questions:
  
  • How much/which classes/types of classes (AttributeDefinitions, DataConnectors, Resolvers?, Filters? Attributes?
  • How many methods to move into the Interfaces:
    
    • All?
    • As few as we can get away with?
    • Those required to perform function, but not for configuration?
• Resources: underway - need to talk to Brent.  This leads to Lifecycle and Services
• Attribute->IdPAttribute or XXXAttribute
  
  • What is the prefix of choice.  Whay should we not just pick IdP and move on?
• Matters arising from the (V2) RegistrationAuthority work (https://github.com/ukf/mdrpi-match-idp-ext/releases)
  
  • What (if anything do we need to do for filters which assume an SP in the context of anonymous lookup.
  • OpenSAML checkstyle with constants in otherwise empty interfaces
  • (by extension other checkstyle issues)

Scott

Completed work on ServletRequestScopedStorageService (i.e.storage via cookie). Pushed all the management of loading/saving data into a Filter interface on the plugin, invoked by Spring proxying filter. SessionManager drops its own cookie with session ID in the normal way, so you get two cookies, one with the session ID, another with the data.

Implemented a "memory" for the matching custom Principal by saving it to RequestedAuthenticationContext, SAML profiles will use to populate AuthnContext in assertion.

Did some work on the view scope for the login form flow, assuming we go with the zero-snapshot execution repository for now to deal with serializability limitation.

Still TODO: a "defaultAuthenticationMethod" feature to direct traffic for an SP to a login flow by default but not as a strict requirement

Also need to decide what to do about External login handler. Not convinced compatibility with V2 is practical because of package naming. Compatibility to V2 External LoginHandler "interface" could be done, but likely every existing case of one would need to change anyway, so is it worth it? I doubt it.

Suggest we produce documentation around use of testbed and encourage people with custom login needs to start experimenting. Should we start talking about "final" config layout before doing that? Like splitting "don't modify" files from the rest?

Tom

Nexus : my bad.

Infrastructure updates Sunday night ? IdP, Jenkins, JIRA, Nexus.

Postpone Jenkins upgrade.

Consistent Maven snapshot artifact version numbers for all modules of a multi-module project for ease of pinning to a "version" of an API.

Is java-support ready to be tagged ?

Yes

Alternative to oro dependency for Velocity escaping ?

Handed off to Daniel.

Talk about Sessions.

AI Reminder : Spring bug

AI Reminder : tag net.shibboleth:parent-v3:1 Sunday

Other