使用Systainsys库与IIS时，独立Web应用免SAML认证配置问题

这个需求完全可以实现，问题出在你仅修改了Cookie路径，但未对新应用的认证规则做隔离处理。以下是具体解决步骤：

核心思路 #

默认网站的SAML认证规则是全局生效的，你需要让新应用所在路径跳过SAML认证，同时确保原有认证Cookie的作用范围不干扰新应用。

具体配置步骤 #

1. 为新应用路径添加隔离配置
   在默认网站的根web.config中，针对新应用的路径（比如假设新应用部署在/PublicApp下）添加<location>节点，明确关闭该路径的Federation认证：

   <location path="PublicApp">
     <system.web>
       <authorization>
         <allow users="*" />
       </authorization>
     </system.web>
     <system.identityModel.services>
       <federationConfiguration>
         <cookieHandler mode="None" />
       </federationConfiguration>
     </system.identityModel.services>
   </location>
   

   其中mode="None"会让该路径完全不使用Federation的Cookie处理逻辑，避免被重定向到身份提供商。

2. 修正原有Cookie路径配置
   你之前设置的path="/MemberPages"需要确保是在默认网站根web.config的<system.identityModel.services>节点下，避免被其他配置覆盖：

   <system.identityModel.services>
     <federationConfiguration>
       <cookieHandler requireSsl="true" path="/MemberPages" />
     </federationConfiguration>
   </system.identityModel.services>
   

   这样原有认证Cookie只会在/MemberPages路径下生效，不会影响新应用。

3. 确保新应用自身配置独立
   如果新应用有自己的web.config，要确保其中没有继承默认网站的SAML相关配置，保持最简的认证设置即可：

   <system.web>
     <authorization>
       <allow users="*" />
     </authorization>
   </system.web>
   

常见问题排查 #

• 若仍出现重定向，检查默认网站是否有全局HTTP模块或Handler强制SAML认证，需将新应用路径排除在其作用范围外。
• 测试前清空浏览器缓存和Cookie，避免旧认证Cookie干扰。

内容的提问来源于stack exchange，提问作者Will Rosner