<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 4/17/13 7:02 PM, Cantor, Scott
wrote:<br>
</div>
<blockquote
cite="mid:BA63CEAE152A7742B854C678D9491383750DDEC2@CIO-KRC-D1MBX01.osuad.osu.edu"
type="cite">
<pre wrap="">
</pre>
<pre wrap="">
Could be, sure. But what's going to instantiate and run them? </pre>
</blockquote>
<br>
<blockquote type="cite">
<pre wrap="">Would we have a MessageHandlerAction that was injected with
MessageHandlers and just ran the handlers as its action behavior?</pre>
</blockquote>
<br>
Yes, absolutely. A general Webflow (and/or new OpenSAML) action
that just takes a MessageHandlerChanin and executes it. That's at
least what I personally have always envisioned. I don't know that
Chad really agreed, which is why he put all the stuff in the IdP as
actions rather than MessageHandlers. This was in my mind the whole
point of the "pushing things down" discussion. (Which we're now
carrying much farther than I had originally envisioned, but that's
fine, I like what we're doing.)<br>
<br>
<br>
<blockquote
cite="mid:BA63CEAE152A7742B854C678D9491383750DDEC2@CIO-KRC-D1MBX01.osuad.osu.edu"
type="cite">
<pre wrap="">This is why
I'm stuck on the idea of using ProfileAction alone, it has an execution
framework ready made to use.</pre>
</blockquote>
<br>
Yes, but the big difference is: The actions and that execution
framework (Webflow) are specific to the server-side processing case,
and assume HttpServletRequest and -Response. It operates on a
ProfileRequestContext specifically geared to that case.<br>
<br>
The more general message processing design we have in OpenSAML
isn't. In particular it was designed to be transport agnostic, and
could handle for example the SOAP client case as well. You could of
course have a MessageHandler impl that *is* server-side and
HttpServlet specific, e.g. ones that validate the blob type of
message signatures, based on data in the servlet request. But in
general, any MessageHandler that isn't itself HttpServlet-specific
could be re-used across both cases. ProfileActions can't - which is
fine, they aren't designed to be.<br>
<br>
And so the MessageDecoders/-Encoders and MessageHandlers are not,
at least by API, specific to any particular transport, or execution
framework. OpenSAML ProfileActions and/or Webflow Actions are,
because they are.<br>
<br>
<br>
<blockquote
cite="mid:BA63CEAE152A7742B854C678D9491383750DDEC2@CIO-KRC-D1MBX01.osuad.osu.edu"
type="cite"><br>
<pre wrap="">
How is that superior to just making them profile actions? Maybe it is, I'm
just not sure I see why yet.
</pre>
</blockquote>
<br>
Neither is superior to the other, they're just different. The stuff
that you're pushing down to OpenSAML is implicitly for the
server-side/ HttpServlet use case, but that's not the only game in
town. <br>
<br>
I think the other big difference is that to me, the ProfileActions
are about "profiles", not general SAML processing. At least, that's
semantically implied by the name. And because of the API, they're
about server-side processing of the profile. Which is fine. I'd
expect to see ProfileActions that really are only realistically for
the server-side use case, like issuing an Assertion, etc. Some of
those might even really by name and purpose be specific to say the
SAML 2 SSO profile or Attribute Query profile, etc. Hadn't really
thought about it, but that's what seems natural.<br>
<br>
<br>
<blockquote
cite="mid:BA63CEAE152A7742B854C678D9491383750DDEC2@CIO-KRC-D1MBX01.osuad.osu.edu"
type="cite">
<pre wrap="">
It's true that a handler would be clearly operating on a subset of the
profile request context, but I expect lots of profile actions will be that
way.
</pre>
</blockquote>
<br>
That's true, and there is a bit of a grey area. I think the
difference, semantically, is that things that are doing "profile
things", beyond general SAML processing, clearly are
ProfileActions. But the grey area is the whole point of my
question. <br>
<br>
<br>
Just to state it out loud, from the message API refactoring docs
that I did [1] my thoughts were:<br>
<br>
<blockquote type="cite">
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
Model message processing as a "logical pipeline":<br>
<ul>
<li>Inbound MessageContext decoded -> invoke inbound
HandlerChain -> "business logic" (aka profile handling)
-> invoke outbound HandlerChain -> outbound
MessageContext encoded.</li>
</ul>
</blockquote>
<br>
So the way I think about this is, what we're really talking about
here is (mostly) the middle part ("business logic" aka profile
handling). That's the part that I see as definitely being handled
by ProfileActions which are coded directly to do things related to
profile-specific logic, or (possibly complex) things that aren't
really about processing a single message in isolation. The first 2
and last 2, in the Webflow execution context, are also actions of
course, but use components (by delegation) that in an API sense
aren't tied to either the server-side context or assumption of
HttpServlet API. (The specific impls that are wired into a specific
flow will of course, e.g. the decoders and encoders are implicitly
the HttpServletRequest/-Response ones)<br>
<br>
I may not be making much sense. I'll stop rambling for the moment.
Maybe a topic for the next call and/or I2MM.<br>
<br>
<br>
<br>
[1]
<a class="moz-txt-link-freetext" href="https://wiki.shibboleth.net/confluence/display/DEV/MessagingAPIRefactoring">https://wiki.shibboleth.net/confluence/display/DEV/MessagingAPIRefactoring</a><br>
<br>
<br>
<blockquote
cite="mid:BA63CEAE152A7742B854C678D9491383750DDEC2@CIO-KRC-D1MBX01.osuad.osu.edu"
type="cite">
</blockquote>
<br>
</body>
</html>