MFA Transition nextFlowStrategy-ref question IdP3.3.0
O'Dowd, Josh
Josh.O'Dowd at mso.umt.edu
Wed Dec 21 16:16:51 EST 2016
Thanks Scott,
I like the idea of the custom-object functions. I had thought of combining the logic in the strategies but, as you said that doesn't really encapsulate the concerns, in this case. It would end up being strange logic, like "if there is an attribute trigger then this flow else if this is a Duo-enabled service provider then Duo flow..."; then have to repeat some of that again downstream, yuck.
Thanks again.
Josh
-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: Wednesday, December 21, 2016 2:07 PM
To: Shib Users <users at shibboleth.net>
Subject: Re: MFA Transition nextFlowStrategy-ref question IdP3.3.0
On 12/21/16, 3:19 PM, "users on behalf of O'Dowd, Josh" <users-bounces at shibboleth.net on behalf of Josh.O'Dowd at mso.umt.edu> wrote:
> My initial though was to find out if I could have a nextFlowStrategy return a flow id OR another strategy-ref.
You can't go directly from script to script as a transition rule, but you don't really have to since you can just add the second script to the logic of the first one. If you want to share logic across steps, you can encapsulate that in a scripted function and inject it as a custom object and call it from other scripts. Or do real Java code to wrap some of it of course.
That's the general gist without getting into the guts of it.
> It would be nice if a strategy could reference another strategy, but I am looking for a “clean” alternative idea.
There are always ways to link together separate blocks of logic, just not in a way that the MFA machinery has to be aware of.
-- Scott
--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
More information about the users
mailing list