Shibboleth Developer's Meeting, September 6, 2013

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

Call Administrivia

Dial-in attendee identification.

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

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.

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

Rod

On vacation at present.

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

Documented some identified issues with SWF (Spring and Web Flow Technical Issues), primarily the known issue of non-serializability.

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.

Planning to look at Session layer next, along with supporting client-side storage service, which led to DataSealer enhancement work.

DataSealer should be used anywhere the IdP needs to MAC and/or encrypt data for its own use. Produces base-64 blobs that are now GCM-encrypted, which builds in a MAC. Each blob encodes a cleartext key alias that's part of the MAC so we can add new keys but still recover old blobs if the original key is left in the keystore.

Thinking down the road we might be able to generate and store fresh keys on a scheduled basis and have it auto-rotate.

Tom

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