Shibboleth Developer's Meeting, March 14, 2014

Call Details

Meeting URL: http://fuze.me/23713651

Note: no dial-in available this week

Attendees:

Call Administrivia

10:00 Central US / 11:00 Eastern US / 15:00 UK

Note: different time than usual for EU participants for the next couple of weeks due to daylight saving differences

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

60 to 90 minute call window.

Brent

Daniel

Ian

Rod

Parsing RelyingPartyConfiguration has thrown up some gaps and things which need addressed.
- Concept of Anynonymous RelyingParty should be added to the RelyingPartyContext (ot can be populated as the V2 decision is currently)
- Some extra configuration (e.g. "DetailedErrors" to be added to the schema
- Need to add embedded <Condition>/<ConditionRef> to the UnidentifiedRelyingParty to allow injection of Conditions via Spring Syntax, We will do same to AttributeResolver, but not right now.
- For now the RelyingParty default is V2 behavior which is match on RP id or EntitiesDescriptor. This can safely use hardwired location of the SAML metadata.
Move all (custom) schemas to a new module
After RelyingParty I'll move onto Metadata config.

Scott

Refactored SSO flows and beans as a first attempt at some reuse, mainly hoping we can factor out the pre/post steps to all the SAML request/response cases
- Note: our approach to booting the flows doesn't work if you inherit, because the "first" state will be whatever's at the top of the child flow, so the Init action has to be explicit in each flow
Refactored persistent ID data connectors from V2 and built a generator with the new API
- Moves computed/stored behavior into strategies much like the transients were done, layers stored on top of computed
- Think we probably want to clean up the StoredIDStore API, but I don't think it's viable to use my storage API for it
In "home stretch" on NameID code, but there's more work to do:
- the StoredIDStore
- clean up terminology in attribute-centric code ported from V2
- handling of name qualifiers in various places
- handling SAML Affiliations allowing SPNameQualifier != requester ID
- do we need reloadability here? how would we do that for native Spring files? I guess a new Service wrapper?
Main gaps in SAML profile work are security functions and handling NameIDPolicy and then deciding how to handle various other AuthnRequest advanced content

Tom

IDP-380 : The Spring Tool Suite plugin for Eclipse seems "invasive" when it automatically adds the Spring nature to projects with Spring dependencies, for example OpenSAML v2, but really helpful when working with Spring wiring. It also seems to slow down Eclipse somewhat, but maybe that is just something to get accustomed to.
INFRA : Gave Jenkins more heap space, hopefully reducing cpu load
IDP-381 : Ran uApprove in Eclipse with IdPv2 as prep for meeting with Halm.
IDP-382 : Mocked up a Selenium test for IdPv2 in Eclipse. Unfortunately, it seems that Selenium does not "wait for" (WebDriverWait) redirects, probably because ours do not present anything to the browser. I was hoping to get access to the SamlResponse in the SAML1 SSO POST profile to compare with v3 as an integration test.

Other