<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
color:black;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
tt
{mso-style-priority:99;
font-family:"Courier New";}
span.EmailStyle17
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.pl-smi
{mso-style-name:pl-smi;}
span.pl-k
{mso-style-name:pl-k;}
span.EmailStyle21
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body bgcolor=white lang=EN-US link="#0563C1" vlink="#954F72"><div class=WordSection1><p class=MsoNormal><span style='color:#1F497D'>Thanks. This was very helpful.</span><span lang=FA dir=RTL style='font-family:"Arial",sans-serif;color:#1F497D'><o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>In the pipeline, where are the set of components/steps that deal with signing objects? I see you’re invoking outbound message handlers, </span><span dir=RTL></span><span dir=RTL style='font-family:"Arial",sans-serif;color:#1F497D'><span dir=RTL></span> </span><span style='color:#1F497D'>and having looked at the hierarchy of AbstractMessageHandler, I don’t see anything that would help me, say, sign an authn request. There are some that validate, but none I have been able to find that actually do. </span><span lang=FA dir=RTL style='font-family:"Arial",sans-serif;color:#1F497D'><o:p></o:p></span></p><p class=MsoNormal><span lang=FA dir=RTL style='font-family:"Arial",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>To find out how the IdP does that sort of thing, I noticed the creation of a security config that is passed along to an MD resolver. What I failed to find was the step that actually did the signing of the response for instance. <o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='color:windowtext'>From:</span></b><span style='color:windowtext'> dev [mailto:dev-bounces@shibboleth.net] <b>On Behalf Of </b>Brent Putman<br><b>Sent:</b> Tuesday, May 19, 2015 10:26 AM<br><b>To:</b> dev@shibboleth.net<br><b>Subject:</b> Re: OpenSAML how-to: adding transport to context<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal style='margin-bottom:12.0pt'><span style='font-size:12.0pt'><o:p> </o:p></span></p><div><p class=MsoNormal>On 5/19/15 4:27 AM, Misagh Moayyed wrote:<o:p></o:p></p></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal>V3 code:<o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal>Something like this perhaps? <o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal><span style='font-size:9.0pt;font-family:"Courier New"'>SimpleRequestAdapter inTransport = new SimpleRequestAdapter(…);</span><o:p></o:p></p><p class=MsoNormal><span style='font-size:9.0pt;font-family:"Courier New"'>MessageContext<SimpleRequestAdapter> inCtx = new MessageContext<SimpleRequestAdapter>();</span><o:p></o:p></p><p class=MsoNormal><span style='font-size:9.0pt;font-family:"Courier New"'>inCtx.setMessage(inTransport);</span><o:p></o:p></p></blockquote><p class=MsoNormal style='margin-bottom:12.0pt'><span style='font-size:12.0pt;font-family:"Times New Roman",serif'><br><br>No, not really. The messaging stuff (message decoding, encoding and handlers) is the part of v3 that changed the most from v2. It's completely different and bears almost no resemblance to the v2 design.<br><br>In particular, the notion of the various "-Transport-" interfaces is completely gone.<br><br>If you haven't found your way to this document [1] yet, this is probably the best we have at the moment on the design of the new messaging API in v3 (although there's no code examples, read on). Some of the terminology, class/interface names changed a little bit from that document.<br><br>The gist of it is:<br><br>- A MessageContext represents a single message, the type of which is represented by the generic parametrization of the context. The generic type could be literally anything, but for our own SAML code it's usually just a SAMLObject, since that is the "payload" of a SAML binding. For another protocol like OpenID or CAS, etc, it would be a similar type which represents the protocol message data structure. For SOAP, it *could* be *either* an Envelope or the type of the payload, depending on whether you want to do "message oriented" vs "payload oriented" messaging; all the OpenSAML SOAP impls do payload, so the context will be paramed as SAMLObject like the other non-SOAP bindings.<br><br>- The MessageDecoders and MessageEncoders operate directly on the type of input they support, e.g. HttpServletRequest and HttpServletResponse. See the interfaces and abstract impls in messaging-api and messaging-impl. Unlike v2, they generally don't do anything other than decode/encode the message from/to the MessageContext, and possibly populate some binding- or protocol- specific subcontexts.<br><br>The unit tests for the decoders and encoders are probably the best non-IdP examples of this code that you could look at.<br><br>- MessageHandlers operate on a single MessageContext and can do anything: evaluate security policy (inbound), populate subcontexts (inbound/outbound), build or mutate the message (outbound), etc.<br><br>- An operation context binds 2 or more MessageContexts together to implement a message exchange pattern. The only current one is the InOutOperationContext, which represents and inbound and outbound flow (either server-side or client) side. <br><br>- As mentioned in the wiki doc, message flows are modeled as a logical pipeline. For a server-side one, it's something like:<br><br></span><tt><span style='font-size:10.0pt'>Inbound MessageContext decoded -> invoke inbound MessageHandler -> "business logic" (aka profile handling) -> invoke outboundMessageHandler -> outbound MessageContext encoded.</span></tt><span style='font-size:12.0pt;font-family:"Times New Roman",serif'><br><br>That's conceptually what the IdP does, but it's a little convoluted at this point, with all the SWF and ProfileAction stuff.<br><br>You can actually now see a good example of a client-side flow in the new SOAP client [2] that I'm literally just finishing up. It's on trunk only, so not released yet. The logic in the send(...) method of org.opensaml.soap.client.http.AbstractPipelineHttpSOAPClient is pretty much the client-side conceptual pipeline model. <br><br>I don't have at the moment any code to illustrate, but a simple server-side pipeline impl would look very similar, except based on HttpServletMessagePipeline and of course the order of operations would be reversed, with inbound decoding first and then outbound encoding last. There would likely be a "business logic" step in between those 2, possibly based on a ProfileAction (which assumes a ProfileRequestContext subtype). When I have a few minutes I will do up an abstract impl of a server-side pipeline, to serve as an example for non-SWF, non-IdP OpenSAML usage. It would actually be simpler than the client-side code in the SOAP client, I think.<br><br><br>[1] <a href="https://wiki.shibboleth.net/confluence/display/DEV/MessagingAPIRefactoring">https://wiki.shibboleth.net/confluence/display/DEV/MessagingAPIRefactoring</a><br><br>[2] <a href="http://svn.shibboleth.net/view/java-opensaml/trunk/opensaml-soap-api/src/main/java/org/opensaml/soap/client/http/AbstractPipelineHttpSOAPClient.java?view=markup">http://svn.shibboleth.net/view/java-opensaml/trunk/opensaml-soap-api/src/main/java/org/opensaml/soap/client/http/AbstractPipelineHttpSOAPClient.java?view=markup</a><br><br><o:p></o:p></span></p></div></body></html>