Versions Compared

Old Version 5

changes.mady.by.user Scott Cantor

Saved on

compared with

New Version Current

changes.mady.by.user Rod Widdowson

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Shibboleth Developer's Meeting, March 14, 2014

...

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 ?

...

  • Javadoc generation JPAR-53
  • Logging and other dependencies JPAR-52
  • "consequences" pass completed

 

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

...