Missing configuration related to activation flow

[Aravinda Liyanage]

HI Scott,

I appreciate that you are taking time to reply and these pointers would be
indeed helpful.

On Wed, Mar 26, 2025 at 4:48 PM Cantor, Scott <cantor.2 at osu.edu> wrote:

> > Thank you Scott for the reply. My thought process was that
> > by using Actions, I wouldn't have to worry about populating
> > the context and parsing data from-to SAML etc.
>
> SAML isn't something you pass data to, so I don't know what your mental
> model is here. You have several errors in all of that XML without even
> looking that closely, and I can't look at it closely because you aren't
> funding us to get support.
>
> Take my advice and just do orders of magnitude less work with less risk.
>
> > Do you suggest ditching two AbstractAction class
> > implementations altogether and just use two servlets
> > (original request handler and callback handler) with
> > `External` login flow?
>
> It can be done with one servlet if it’s smart enough, but there are other
> things you'd have to do to construct a properly implemented flow with the
> same features as we already provide.
>
> That one servlet or two at most replaces virtually everything you posted
> there with a supported API contract that will survive upgrades.
>
> > Since, the workflow needs to be paused while
> > redirects/internal authentication process and no custom
> > AuthenticationFlow is involved, is there anything to do to
> > preserve the context or it can be retrieved by default using
> > conversation key?
>
> It's resumed with the key and it would have to be anyway, you can't avoid
> that if you're going to redirect somewhere else. Any servlet that has to go
> somewhere else to do the actual work has no choice but to propagate that
> key and get it back to resume things.
>
> For example, to implement SAML proxying, we had to pass the flow execution
> key inside the RelayState or we could never have resumed the conversation
> either. It's just a requirement to do any work that's not part of the IdP
> in the middle.
>
> Additionally, do not use the authenticationFlows profile option, it will
> be deprecated in 5.2, and removed in 6.0. You don't ever directly tell the
> IdP what flows to run that way, the defaultAuthenticationMethods setting is
> how that's controlled if you want to impose rules at the IdP.
>
> -- Scott
>
>
>

-- 
Best Regards,
Aravinda Madushanka.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20250326/ad047792/attachment.htm>