<div dir="ltr">Well,<div>In the professional world things are way more complicated. </div><div>TBH, a decision has been taken to go out of Shibboleth and aim to run only on azure B2C(lack of openidconnect support is a huge problem). This last work is an attempt to provide a federation between azure B2C to keep an SSO between old and new applications.</div><div>Moreover, I have to evaluate this "bridge" in only 4 days...</div><div>So I do agree that in the best world, </div><div>- with an infinite time and budget</div><div>- no organizational constraints,</div><div>- full understanding from the top management that we have to make long term decision</div><div> migration to IDP4 is the best bet. However, this world doesn't exist and I'm just able to do the best I can.</div><div>So don't kill the messenger ;-). I'm just an external consultant who hasn't the power to influence the whole way of working of my client.</div><div></div><div>Regards,</div><div>Claude </div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le jeu. 16 juil. 2020 à 23:58, Peter Schober <<a href="mailto:peter.schober@univie.ac.at">peter.schober@univie.ac.at</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">* Claude Libois <<a href="mailto:clibois.work@gmail.com" target="_blank">clibois.work@gmail.com</a>> [2020-07-16 17:38]:<br>
> The SAML Proxy login flow is clearly the cleaner solution. However, Our<br>
> planning is too short and risky to do a migration from 3.4.1 to 4.x. I will<br>
> check with our infrastructure however.<br>
<br>
You did see my remark (or official announcements) that IDP v3 will be<br>
EOL'd and out of support by the end of the year? (Of course v3.4.1 is<br>
also out of support, current is 3.4.6. If any security bugs were<br>
discovered you'd have to update to a current version there, too.)<br>
<br>
Would you prefer to be pressured into a "short and risky migration" to<br>
v4 should a critical security issue be discovered in the near future<br>
(or be left vulnerable with a system you can't update within a few<br>
hours/days)?<br>
<br>
> I will also check if by any chance this feature have been<br>
> back-ported (or if I can backport it).<br>
<br>
You really think backporting significant new features from IDPv4 to v3<br>
yourself is a good idea[1]? Did you even look at the documentation for<br>
the parts involved? And you think this would be easier than upgrading<br>
your v3 system to v4 (or just putting an SP in front of your<br>
unmodified IDP)? Good luck!<br>
-peter<br>
<br>
[1] Even if you were successful in such an endeavor (as far as you<br>
know) you'd consequently be running code noone else in the world is<br>
running, for a security service, after all. If obscurity worked that'd<br>
probably be a very secure system.<br>
-- <br>
For Consortium Member technical support, see <a href="https://wiki.shibboleth.net/confluence/x/coFAAg" rel="noreferrer" target="_blank">https://wiki.shibboleth.net/confluence/x/coFAAg</a><br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net" target="_blank">users-unsubscribe@shibboleth.net</a><br>
</blockquote></div>