Not in whitelist or domains in whitelist are malformed

Follow
    Applies to:
  • SecureAuth Identity Platform
Deployment model:
  • Cloud
  • Hybrid
  • Version Affected: 9.2+

     

    Description:  

    A WSFederation realm logs the following error:

     

    Not in whitelist or domains in whitelist are malformed. Url:  https://mail.domain.com/ecp

    Exception occurred: System,IdentityModel.Protocols.WSTrust.InvalidRequestException: Not in whitelist

     

    Cause:  

    Whitelisting was introduced for the wreply field in WSFederation realms, from the following hotfix versions:

    9.2.0-36

    9.3.0-21

    19.07.01-30

    20.06-6

     

    Domains not in the whitelist will be blocked.

     

     

    Resolution:  

    The whitelist can be defined in 2 different places.

    1. For a single domain, the value in the "WSFed Reply To/SAML Target URL" field acts as a wildcard for any URLs with the same domain, e.g.: 

     

    mceclip0.png

     

     

    2. If multiple domains need to be whitelisted then decrypt the web.config, then edit it to add the following line in the appSettings section:

     

    <add key="WsFedWhiteList" value="domain.com,mail.domain.com,anotherdomain.com" />

    The value should be a comma delimited list of hostnames only.

     

    Note for the vast majority of cases the above should be sufficient.  Most integrations of Office365 will always use the wreply value but there are some use cases when integrating with MS Exchange where the wreply value is not present.  Therefore in order to use a dynamic URL the redirect URL is derived from the appliesto attribute.

    In order to change from wreply to appliesto, add the below appSetting and ensure it is set to "true".

     

    <add key="IsExchangeService" value="True" />

     

     

    SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

    Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.

    0 out of 0 found this helpful

    Comments

    0 comments

    Please sign in to leave a comment.