Blog

We are far from the days when logging in was as easily implemented as a username, password, and cgi script in between your user’s anonymous and logged-in states. Today’s world is ruled by powerful web access management softwares that not only securely keep intruders from accessing your most secure pages but also allows for a user management system hooked up to your LDAP environment. Among them: HP’s IceWall SSO, IAM (Identity and Access Management), and CA Siteminder. Let’s focus on the latter.

Per their website, CA Siteminder promises to keep the door opened for users and closed for hackers in these terms:

“Transform your business by giving employees, customers, partners and suppliers secure access to essential information and applications whether on-premises, in the cloud, from a mobile device or at a partner’s site. As your organization’s Web applications increase, you want to provide a seamless user experience by allowing your users to sign on once to access all of their applications while protecting your organization from breaches and other threats. With CA Single Sign-On, you get flexible and secure identity access management.”

Indeed, we live in a world where hacking has become an extremely popular international criminalized sport and companies heavily invest in (re-)gaining their customers’ trust. It is more than likely that an Oracle WebCenter Sites (WCS) project implementation requires a Siteminder consideration as it acts as a filter to malicious activities, and provides multiple levels of access for every single user in a single realm. Thus, how can we leverage within WCS, the CA agent layer that would protect our pages?

First, we need to differentiate between two concepts: Secure pages and Public pages. For the sake of simplicity, let’s assume that secure and public pages have no intrinsic differences. We can define them as instances of a ContentPage asset type. Here is our ContentPage Asset Definition schema:

ContentPage_CD (body, pageType)

We will use the pageType (ContentPage_A) attribute to tag the content as either being public or secure. The attribute is formatted by a pull-down attribute editor:

<?XML VERSION="1.0"?>
<!DOCTYPE PRESENTATIONOBJECT SYSTEM "presentationobject.dtd"> 
<PRESENTATIONOBJECT NAME=“PageTypePulldown”>
<PULLDOWN>
  <ITEM>Public</ITEM>
  <ITEM>Secure</ITEM>
</PULLDOWN>
</PRESENTATIONOBJECT>

Now let’s create two page assets. Page1 is tagged as “Secure”.

page1.png

Figure 1: Page1 (ContentPage_C) view in content contributor interface 

Page2 is tagged as “Public”. 

page2.png

Figure 2: Page2 (ContentPage_C) view in content contributor interface

We do want our pages with proper vanity URLs generated for each as they will be needed by the CA Agent. Page1 shall be /secure/page1.html while Page2’s URL reads /page2.html. We can achieve this requirement either with a filter (see Mitul's post about Creating a Custom Flex Filter in WebCenter Sites and tweak it a bit) or with a clever vanity URL Pattern. The latter is quite interesting as it uses syntax that Oracle does not specify in their broad documentation:

${(empty pageType or pageType == "Public")? f:spaceToDash(name.toLowerCase()) : (pageType.toLowerCase()).concat("/").concat(f:spaceToDash(name.toLowerCase()))}.html

As you can see, we are pulling the pageType attribute value only if it reads “Secure”.

Consequently, the resulting vanity URLs are:

page1_url.png

Figure 3: Page1 (URL tab)

page2_url.png

Figure 4: Page2 (URL tab)

We now have our two pages ready for testing. In Siteminder, configure the agent to intercept all /secure/* requests and redirect to the login.html containing your login form. What should happen next is that once a user attempts to access Page1, Siteminder will intercept the said call, check if the user is authorized to access the resource based on its policy settings. If the user is not authorized, the response redirects to the login page. The user enters his/her credentials and submits. Siteminder either grants access (authenticates) or denies the user to proceed. If authentication goes smoothly, the user can access Page1. As a developer, we can use Siteminder’s posted header values (via persistent and non-persistent sessions) to determine if a user is in authorized mode (and logged in) or not.

If you are wondering about Page2... It is accessible whether in anonymous or authorized mode as Siteminder never intercepts its URL.

The example above tracks vanity URLs. However, what about WCS’s internal URL patterns? Those would be handled as usual with proper rewrite rules in the httpd configuration file. As a precaution, please ensure that you block (to the outside world only) any servlet not being used to serve pages such as: CacheServer, CatalogManager, ContentServer, DebugServer, HelloCS, etc… You can find a complete, non-exhaustive list in Oracle’s WCS Support website (https://support.oracle.com). While you are at it, disable access to all URLs with pagename parameters specifying fatwire, FutureTense, OpenMarket, Support, or WebServices.