<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
&gt;Very good point. I guess it&#39;s just on my mind as I&#39;m putting together a proposal to patch the code behind a Shib IdP RemoteUser check to chain on to an ADFS IdP rather than throwing up a form that does an LDAP-bind against AD (all part of the joy of using Office365 for email, needing a WS-Trust based IdP for things like Lync, and various internal web apps that authenticate directly against the system RemoteUser chains too).<br>
<br>
</span>So I guess that whole move by MS to browser login for all the apps isn&#39;t moving along very quickly then...?<br>
<div class=""><div class="h5"><br></div></div></blockquote><div><br></div><div>See <a href="http://blogs.office.com/2014/11/12/office-2013-updated-authentication-enabling-multi-factor-authentication-saml-identity-providers/">http://blogs.office.com/2014/11/12/office-2013-updated-authentication-enabling-multi-factor-authentication-saml-identity-providers/</a> paying special attention to &quot;<b><i>There is no change to the way sign in works in the Office clients after you have the update. By default the new ADAL based authentication stack is disabled. The new authentication features must be enabled on each client machine and also for the Office 365 tenant that you are connecting to.</i></b> &quot; </div><div><br></div><div>Getting that configured on all the potential desktops, let alone mobile/tablet devices (assuming they are even running appropriate versions of software) is unfortunately not a realistic goal, and inevitably it will be users like Prince Ipal and Dean O&#39;Faculty that would be hit by switching ADFS to use Shibboleth.</div><div><br></div><div>Phil</div><div><br></div></div></div></div>