Shibboleth Developer's Meeting, September 6, 2013

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

Call Administrivia

Dial-in attendee identification.

...

60 to 90 minute call window.

Brent

Continuing to work on metadata resolver refactoring.  Conversion to MetadataResolver API and pre-processing model is largely complete.  Main outstanding issue is design of how/where to do per-node processing for things like EntitiesDescriptor@Name and shib:KeyAuthority.  A concern and desirable goal is to reduce unnecessary treewalking. Choices are:

• New plugin abstractions for MetadataResolver itself
• MetadataFilter impl which does 1 treewalk and takes plugins similar to #1
• Just implement each as a MetadataFilter unto itself, so each does own treewalk.  Advantage is no new abstractions.

Refactored MetadataCredentialResolver to use new credential caching mechanism based on XMLObject#getObjectMetadata class-to-instance multimap.

Refactored HTTP metadata resolvers to use Apache HttpClient v4.  Some TODO's remaining around capabilities differences to v3 client.

Also a variety of other interface and base class impl cleanup; removing old interfaces, etc;  simplifying and fixing up the ChainingMetadataResolver.

Daniel

 Next up: finalize and implement the plugin processing above.  Finish up HttpClient refactoring. Start on dynamic metadata resolver.

Daniel

Connected with Rod to get Velocity template work done for RDBMS connector

Next up, LDAP security config and LDAP authentication

Ian

• eduGAIN and Shibboleth services 
• Jenkins and nightly build plan
• Metadata Aggregator

...

From email to Tom : AttributeMapper config via AttributeResolver, DataConnector tests and logging, injecting Velocity into RDBMS and Ldap DC.

Tom AI : Ask for more details about the "Spring inside V2" code issue.

Tom AI : Ask Rod to investigate FilesystemResource + ClasspathResource -> SomethingResource which understands "classpath:* and "file:*" semantics ala everything else as part of Resource review.

Scott

Completed first batch of authentication work:, documented at Authentication

• Context design
• Configuration and selection of flows
• SSO via active results pulled from session (session itself is TBD)
• Implemented and tested flows for IP authn, asserted RemoteUser or header, and form/basic-auth to JAAS
• Successful integration of nested subflows for Authentication into MVC profile testbed
• Explored error handling a bit
• Handling of AuthnContext, including non-exact matching

...

Aside from polish, and those issues, an outstanding area of concern is how the SAML 2 SSO handler will figure out how to populate the AuthnContext in the response. Might need some adjusting of the design at that point.

Some other TODOs:

• Native Kerberos and LDAP validation actions
• an option for "external" authentication, this uses a separate servlet in V2, so what's the approach we should take?

Also defined a subflow integration point for subject canonicalization and tested "simple" implementation.

...

Jetty, java-shib-testbed, idp-distribution, idp-war, SWF, Velocity wiring, external flows and templates, idp-conf, Version.java (sigh), aacli.sh and version.sh, refactor idp-core, git.

Oh, the Installation, Directory, Configuration, Upgrade wiki pages.

Questions (apologies in advance, if we run out of time) :

What is current state of thought regarding name format semantics for an EntityID, like NameID ?

Why are target (redirect) URLs not in the SAML spec ? e.g. why are query strings "required" in addition to assertions 

Other