This is a fairly common request from our SiteMinder clientele.

“We would like to be able to “flip a switch” when we have some kind of notification that we need to share with all of our website users/customers.  Once the switch has been flipped, the users should be redirected to this page immediately upon login.  After acknowledging the notification, they should be taken to the original page they were requesting.”

Possible uses:

• There is a new offer that we want our customers to see.
• We want to make sure customers have read our “terms and conditions” page before they are allowed to access some protected content.
• We have a new customer account requirement, such as Forgotten Password Challenge Response Questions, and we want customers to be redirected to a page to fill out those questions if they have not already done so.

We have seen other companies try to enforce this without CA SiteMinder, using their own redirects after login.  The problem there is that the user can often circumvent it by manually changing the URL again to the page he was trying to get.  The benefits of using CA SiteMinder to enforce this, is that you are controlling it at the authorization level, and not simply putting in a post-login redirect.  So there is no way for the user to ignore it and manually change the URL to what he was originally trying to access without first acknowledging the notification/completing the required account maintenance/etc.

SiteMinder’s Advanced Password Services (APS) has a built in feature that makes this a little simpler, but you can do it with out-of-the-box SiteMinder functionality, with just a little more work.  Here’s how:

Assumptions and notes for this example:

There is an attribute in your LDAP or DB that is used as a flag to tell if the user has or has not seen the notification.  For the example below it’s called “hasreadnotification” and 0 means no, anything non-zero means yes.  In this example, we will cover the scenario where you want your customers to see the “terms and conditions” page.  The policy user entry pieces are shown below in LDAP format, it would be different for DB’s.  The terms and conditions page is located at /pages/termsandconditions.asp.  This page must have 2 capabilities:

• It must be able to flip the bit in your LDAP or DB when the user acknowledges the notification.
• It must be able to read a cookie and redirect the user there after he acknowledges the notification.

Steps:

1)       Turn off caching of negative authorizations

When using SiteMinder’s authorization cache, it will store a user’s success or failure to be authorized for a given page.  In a scenario where you may be temporarily rejecting a user’s authorization because they need to read a notification first, you do not want SiteMinder to cache this rejection.  As of SiteMinder 6.0 sp5 cr011, you can disable the caching of authorization failures so that once the user is done reading the notification, and tries to visit the page again, he is not rejected due to cache.

• Open regedit (or open sm.registry file if your policy server is on UNIX)
• Navigate to HKLM–>Software–>Netegrity–>CurrentVersion–>Ds–>DsCacheParms
• Change: DsInfoEnabled=3 (NOTE: this is contrary to what is in the SiteMinder release notes, it is a doc bug)
• Close regedit
• Restart the Policy Server

2)       Update login form to store the originally requested page in a cookie

The target page that your user was originally requesting will be lost when he is redirected to the notification page.  The simplest way to overcome this is to configure your fcc login page to store the target in a cookie.  Then this cookie can be read by your notification page, to send the user there after he acknowledges the notification.

• Open your fcc file in a text editor
• At the top amongst the other @ directives, insert the following line:      @smtransient=TARGET
• Save and close the file

3)       Update policies to disallow users who have not seen the notification

In each policy that controls access to pages that should only be seen by those who have acknowledged the notification, you must put a new entry into the policy to prohibit authorization for anyone who hasn’t.  This can be very tedious if it applies to a large set of realms, but there is no good way around it, since Global Policies apply to all users and we only want these new policies to apply to users who have not acknowledged the notification.

• Open the policy
• On the users tab, enter:             (hasreadnotification=0)
• Click “Add to Users”
• While that new entry is still highlighted, click the “Exclude” button.
• Click OK to save and close the policy
• Repeat for all relevant policies

4)       Create AccessReject rules

This one cannot be done at the Global level, because Global Rules only show up when adding rules to Global Policies.  So in each realm that governs access to pages with the notification restriction, you will need to create a new rule.

• Under each relevant realm:
• Right click on the Realm and Create Rule under Realm
• Name the rule AccessRejectRule
• Select the proper Agent or Agent Group
• Leave the resource as *
• Under Action, select Authorization events, and then OnAccessReject from the dropdown list
• Click OK to save and close the rule

5)       Create redirect Responses

This is the only piece that can be done at the Global level, and it will show up in the available responses when adding responses to any of your policies.

• Under the Global Policy tab
• Right click on Responses, and Create Response
• Name the response RedirectToNotifyPage
• Click the Create button
• In the dropdown, select WebAgent-OnReject-Redirect
• For Variable Value, enter /pages/termsandconditions.asp
• Click OK, OK to save and close the response

6)       Create new Policies to redirect users

This one cannot be done at the Global level, because Global policies have to apply to all users, and we only want this redirect to apply to those who have not read the notification.  In each policy domain that has realms which govern access to pages with the notification restriction, you will need to create a new policy.

• Under each relevant domain, right click on Policies, and Create Policy
• Name the policy RedirectUsersToNotifyPage
• Under the users tab, in the manual entry field, enter:    (hasreadnotification=0)
• Click Add to Current Members
• Under the rules tab, add the AccessRejectRule rule
• Highlight that rule, and click Add Global Response
• Select the RedirectToNotifyPage response
• Click OK, OK to close and save the Policy

That’s it for the SiteMinder configurations.  When you want to engage this functionality, run an LDAP or DB script to set hasreadnotification=0 in the necessary user accounts.  This tedious setup can often be recycled with very little effort.  If a new required notification comes up, located at a different URL, it can be as simple as changing the Value in the Response and then rerunning the LDAP or DB script that sets hasreadnotification=0 in the necessary user accounts.

[Photo credit: JoshuaDavidPhotography.COM via Flickr]