Changes to web flow action proposal

[Brent Putman]

On 4/17/13 7:02 PM, Cantor, Scott wrote:
> Could be, sure. But what's going to instantiate and run them? 

> Would we have a MessageHandlerAction that was injected with
> MessageHandlers and just ran the handlers as its action behavior?

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.)


> This is why
> I'm stuck on the idea of using ProfileAction alone, it has an execution
> framework ready made to use.

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.

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.

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.


>
>
> How is that superior to just making them profile actions? Maybe it is, I'm
> just not sure I see why yet.

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. 

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.


> 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.

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.


Just to state it out loud, from the message API refactoring docs that I did [1] my thoughts were:

> Model message processing as a "logical pipeline":
>
>   * Inbound MessageContext decoded -> invoke inbound HandlerChain -> "business logic" (aka profile
>     handling) -> invoke outbound HandlerChain -> outbound MessageContext encoded.
>

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)

I may not be making much sense.  I'll stop rambling for the moment.  Maybe a topic for the next call
and/or I2MM.



[1] https://wiki.shibboleth.net/confluence/display/DEV/MessagingAPIRefactoring



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/dev/attachments/20130417/17c35d2d/attachment-0001.html