How To: Configure a Group-Restricted Helpdesk Realm Behind Secure Portal

Version Affected: All

 

Overview

This article explains how to configure a Secure Portal so that an Account Management (Helpdesk) realm is only shown to, and only usable by, users in a specific group.

Secure Portal shows or hides destination realms based on each realm's own group restrictions.

Setting a group restriction directly on an Account Management realm also blocks that realm from looking up users outside the allowed group — so administrators outside the group can no longer manage those users at all. Routing access through an intermediate realm avoids this: the intermediate realm carries the group restriction and Secure Portal visibility logic, while the Account Management realm itself stays unrestricted so it can still look up any user.

Configure a Group-Restricted Helpdesk Realm Behind Secure Portal

This configuration uses 3 realms:

• First realm: the Secure Portal realm.
• Second realm: an intermediate realm that enforces the group restriction and generates the cookie used to sign in to the Helpdesk realm.
• Third realm: the Account Management (Helpdesk) realm.

1. Create the Secure Portal realm (first realm) following SecureAuth's standard Secure Portal Single Sign-On Configuration guide.
2. Create 2 copies of the Secure Portal realm — these become the second and third realms below.

On the intermediate realm (second realm):

3. On the Overview tab, give the realm a Page Header name — this is the name shown in the portal, for example Account Management.
4. On the Post Authentication tab, set Authenticated User Redirect to Custom Redirect.
5. Set Redirect To: to ../SecureAuthXX/Authorized/ManageAccounts.aspx, replacing XX with the Helpdesk realm's (third realm's) number.

6. On Post Authentication > Forms Auth/SSO Token, click View and Configure FormsAuth keys/SSO token.
7. Under Forms Authentication, set Name to a value different from the Secure Portal realm's — otherwise the realm redirects to SecureAuth.aspx and tries to read the wrong Forms Auth/Post-Auth cookie pair, instead of reading the Pre-Auth cookie as intended, and ends up redirecting to restart.aspx.
8. Under Authentication Cookies, copy the Post-Auth Cookie value from the Secure Portal realm into the Pre-Auth Cookie field on the intermediate realm.

9. If users should stay signed in to the Secure Portal, set Clean Up Pre-Auth Cookie: to False.
10. On the Workflow tab, set Receive Token: to Token.
11. Set Require Begin Site: to True.
12. Set Begin Site URL: to /SecureAuthXX, replacing XX with the Secure Portal realm's number.
13. Set Default Workflow: to Username & Password | Second Factor if an additional authentication factor is required, or Username & Password if not.
14. Set Public/Private Mode: to Private Only.
15. On the Data tab, set the group restriction under User Groups to the group that should be allowed access to the Helpdesk realm.

On the Helpdesk realm (third realm):

16. On the Overview tab, name the realm as desired.
17. On the Post Authentication tab, set Authenticated User Redirect to Account Management.
18. On Post Authentication > Forms Auth/SSO Token, click View and Configure FormsAuth keys/SSO token.
19. Under Forms Authentication, set Name to the same value as the intermediate realm's Post-Auth Cookie.
20. Under Authentication Cookies, copy the Post-Auth Cookie value from the intermediate realm.

21. On the Workflow tab, set Receive Token: to Token.
22. Set Allow Transparent SSO: to True.
23. Set Begin Site URL: to /SecureAuthXX, replacing XX with the intermediate realm's number.

On the Secure Portal realm (first realm):

24. Go to Post Authentication, click View and Configure the portal page, and check the box for the intermediate realm.

A user who is a member of the group set on the intermediate realm's Data tab sees the Helpdesk tile in the portal. Selecting it runs the intermediate realm's authentication workflow, then lands the user directly on the Helpdesk realm's post-authentication page.

 

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.