SecurePortal restricted realms still visible when using WebService

    Applies to:
  • Legacy SecureAuth IdP
Deployment model:
  • On Premises
  • SecureAuth IdP Versions Affected: All


    When using the Secure Portal, realms can be hidden with a group restriction. However when the realm to be hidden uses a Web Service Data store, the realm is still visible even when the authenticating user is not a member of the restricted group.



    The required group restriction is not correctly set on the realm itself and/or the Portal Page Authorization is incorrectly set. 



    Add the restriction into the Web.Config of the realm so that it does not show in the Secure Portal unless a user is in the correct group:

    1. Open up the Admin Console
    2. Go to the System Info tab of the realm you wish to restrict
    3. Scroll to the bottom and click the button to edit the web.config
    4. Search for the line starting:

    <add key="UserGroups"

    5. Change the line so it reads as below, replacing GROUPNAME as appropriate:

    <add key="UserGroups" value="GROUPNAME" />


    6. Save.
    7. While still in the Admin Console, click on the Support Portal realm in the left hand pane, then click on the Post Authentication tab.
    8. Now click "View and Configure the portal page" to open the Portal Page Builder.


    9. Select Token Required from the Portal Page Authorization drop down:mceclip2.png 

    10. Click Save.

    Now the realm should only be visible to members of the group specified.


    Additional information:

    Setting Token Required on the Portal Page Authorization dropdown is equivalent to setting the following in the web.config for the Support Portal:

    <add key="PortalTokenRequired" value="1" />


    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



    Please sign in to leave a comment.