PicketLink Federation v2.0 Discussions

[anil.saldhana]

PicketLink Federation v1.x has been popular and been adopted by the community.  As developers, we have learned a few lessions and seen what works and what does not work.

Toward this, PL developers have decided to branch the current work into  (Branch_1_x) and move the trunk to v2.x

As part of 2.x,  the following work needs to happen:

• JAXB2 model replaced by faster and tightly controlled stax model.  (Currently 1.x model has a jaxb/dom model for xml signatures).
• STS Consolidation
  • STS layerization (core, protocol, subprotocol) to cater to soap, rest, xml over protocols http, jrmp etc.
  • Move the SAML2 IDP infrastructure to utilize the STS core infrastructure.

In the next few days, I want to start discussions on the architecture via diagrams.

UPDATE:  The STS architecture discussion is here.

[anil.saldhana]

Stax while giving better performance and control may also mean that we underestimate the effort needed to implement the stax parsers.  Also the error handling has to be done by the stax parsers (which may be implicitly provided by JAXB processing).

Schema validation in the stax world can be performed using JAXP.

[anil.saldhana]

XML Signature/Encryption work on DOM representation of the xml message.  So to cater to xml security, one of the representations has to be DOM.

I feel that we should retain our current structure:

• Message appears on the wire.  We parse as document (DOM). Then apply xml dsign and enc operations on it. Then convert the dom model/original message to an object model using stax.
• We are sending a response back to requestor.  We have the object model.  Build a DOM structure. Apply xml security as needed. Then send the DOM message on the wire.

[anil.saldhana]

Further work has identified:

(08:41:59 AM) anil: stefan: the SAML object model is very very large which means that we have to reuse the JAXB object model for SAML.  We do stax parsing but the JAXB object model.  For wst, we can just use your wrappers. 
 (08:42:36 AM) stefan: anil: I see, so you want to reuse the JAXB objects when parsing with Stax
(08:43:21 AM) anil: stefan: for saml yeah.  it is just too large. 
(08:43:39 AM) anil: stefan: maybe eventually we can build an object model for the saml specs in parallel.
(08:44:05 AM) stefan: anil: what about WS-T? do you think we can replace the object model?
(08:47:05 AM) anil: stefan: u have wrapper classes, that should be fine for now.  the stax parsing will call ur wrappers.
(08:48:08 AM) stefan: anil: I have wrappers for the most complex classes, those with Any elements that accept a large number of options
(09:07:25 AM) anil: stefan: if we need anything more, we can add it to the wrappers.