Page Comparison

Intro

For general details of v3 messaging API, see also MessagingAPIRefactoring.

v2 made use of a statically defined hierarchy of message context subtypes to expose various properties related to message processing. v3 uses a more flexible design based around the notion of contexts which expose class-indexed (and therefore type-safe) subcontexts.  The actual nature and use of message contexts for various message processing use cases is not dictated by the fundamental API.  Each processing case can use the contexts and abstractions appropriate for its needs. 

...

• SamlMetadataContext - IdP right now treats as direct child of MessageContext, Javadoc states is implicit it refers to the "issuer" of the message represented by the context.
  
  • In at least outbound case, need both peer and local metadata
  • Seems would make most sense if usage is symmetrical and done the same way for all entities represented in the context

  • Action AddSamlMetadataToMessageContext would need to change, probably need 2 of them (for peer and local) or have it take a enum param as to which to populate

• v2 associated the metadata role QName with local and peer entity explicitly.  What Chad had in v3 so far puts it on protocol context, so just 1 slot.  Seems it really should be associated with the info identifying the actor, not the protocol under which the message exchange is happening
• What Chad had in v3 so far has relayState on protocol context.  We have now added a binding context, for reasons that arose during the encoder/decoder refactoring - should move it there?
  
  • Binding context is specific to each message context, so if move to binding context then something has to copy from inbound binding context to outbound binding context.
  • Alternative is to put it on the operation context (in IdP the profile context), but so far things like encoders and decoders only know about the direct message context on which they operate.
• In general, given 1) the context hierarchy model and the 2 message contexts (inbound and outbound) 2) that OpenSAML is lower level than the IdP, there is an implicit need somewhere (likely the IdP) to duplicate some data/contexts from the inbound to the outbound message contexts.  Can we avoid this?
  
  • Maybe. Perhaps the model of storing/retrieving information in the MessageContext because that is what the component is handed per its interface is too simple.  Maybe instead we make liberal use of the ContextDataLookupFunction notion, allowing storing the data in one place, e.g. the InOutOperationContext (in the IdP the ProfileRequestContext subclass thereof).
  • Examples
    
    • Info about the inbound requester is needed both in things that process the inbound message context and the outbound message context, e.g. inbound-oriented handlers and message encoders.
    • SAML protocol info and esp relay state are relevant and used in both the inbound and outbound message context. Those apply to the whole message exchange, not just the inbound and/or outbound message.
      
      • Issue with the relay state: Decoders know about and extract relay state.  But since they create and return the decoded message context, there is at that point no parent to the MessageContext.  So probably have to live with storing relay state on the binding context and then either copying it somewhere for encoding, or use a ContextDataLookupFunction to get at it in the inbound message context.
        
        

Other issues

• Do we maintain the reusable components in OpenSAML that represent general lower level SAML processing needs and not specific to the (higher level) IdP?
  
  • Mostly talking about things that were formerly called SecurityPolicyRules, and would now be the more general MessageHandler abstraction, e.g. inbound signature validation, replay detection, message issue instant eval.
  • Chad didn't want to in general (why?), so some things he has currently implemented as actions in the IdP, e.g. for replay and message issue instant
    
    • This wouldn't seem to make as much sense for the more complex security and trust engine related rules
  • Brent generally thinks our original notion was correct and that code should be pushed generally speaking to the lowest level where it makes sense

...