Webinar: Extend Your SiteMinder Portal for Less Time, Hassle, and Money

CoreBlox and Radiant Logic recently teamed up for a webinar to explore how you can stop spending so much time and energy managing your SiteMinder portal. Business doesn't stand still-and your portal's evolution is stalled by the increasing complexity of today's identity infrastructures, and the mounting costs of making changes. For SiteMinder to work its magic at the security layer, it needs one logical access point to a coherent and comprehensive identity system. The webinar explored how a federated identity service based on virtualization allows enterprises to leverage identity stores and unify profiles across security domains to support federation, extend SSO, and enrich authorization policies. Radiant Logic's Elle Griffin discussed how virtualization enables your portal to grow along with your business, and Coreblox President Todd Clayton offered insights based on real-life customer deployments.

You can view the following videos to gain an in depth understanding of this flexible approach for architecting your identity infrastructure:

Part 1 (17 minutes and 8 seconds): Extend SSO and Federation for Your SiteMinder Portal

Part 2 (40 minutes and 16 seconds): Extending SiteMinder with Federated Identities

Protecting Resources with the SiteMinder SAML 2.0 Authentication Scheme

CA SiteMinder supports SAML 2.0 federation both outbound to a Service Provider (SP) when acting as an Identity Provider (IdP) and inbound assertions from an IdP when acting as a SP. Similar to the way other authentication mechanism are handled, a SAML 2.0 Template authentication scheme is used to secure resources for inbound federation from an external IdP to SiteMinder acting as a SP. Several considerations are required before using the SAML 2.0 Template authentication scheme. Unlike other authentication schemes, if you access a resource protected by the SAML 2.0 Template directly with no SiteMinder session (SMSESSION) or no SAML 2.0 assertion, SiteMinder will throw a 500 error instead of automatically redirecting for authentication. Additionally, there is no easy mechanism to allow users to still use another authentication mechanism like forms authentication to access those protected resources. There are several ways to address these limitations, but it depends on what the requirements are for the solution. Will the inbound federation being solely IdP initiated? Do users need to access resources directly and then need to be redirected to the IdP for authentication? Do users need to access a resource directly and be authenticated either through federation or another mechanism like forms authentication? Is there a landing page or do users need to access specific resources within the application directly (deep links)? Understanding these requirements is key to identifying the appropriate approach. Several options for these requirements are outlined in this article.

IdP Initiated Federation

IdP initiated federation request are the most straightforward. The link to the SiteMinder secured resources at the IdP can be crafted such that the assertion is posted to SiteMinder on the initial request. SiteMinder will then process the assertion, establish a session and allow access to the resource if the assertion is valid and the user is authorized to access the resource. The user will then be redirected to the specific landing page specified in the authentication scheme or, if enabled, specified in the RelayState parameter sent to SiteMinder. The default landing page is specified in the Target parameter on the SSO tab of the SAML 2.0 Auth Scheme Properties dialog. To allow the IdP to specify a specific target for deep linking, check the Relay State Overrides Target checkbox.

Redirecting to the IdP When Users Directly Access Resources Protected

Handling the scenario where a user is going to directly access a resource adds a slight complication. As I mentioned above, without special handling SiteMinder throws a 500 error. In the case where there is no deep linking to a specific target, The authentication scheme’s Server Error URL can be used to redirect either for an authn request or over to the IdP. Since this is a static URL, though, the original target cannot be preserved. Click the Additional URL Configuration button on the authentication scheme Advanced tab. Check the Enable Server Error URL checkbox and specify the redirection URL.

If preserving the deep link is required, another approach is necessary. The easiest solution is to use an interim HTML Forms authentication scheme to contain the logic. When SiteMinder redirects for form authentication, the originally requested resource is maintained. This logic can be leveraged to perform the necessary redirect with a RelayState parameter on the URL. The approach I like to use for this is to use a customized FCC page with JavaScript for the redirection logic. The resource is then protected with the customized forms authentication scheme instead of the SAML 2.0 template. A second redirection page protected by the SAML 2.0 Template is used to then redirect back to the originally requested resource. While I would prefer to handle the redirection through an additional parameter on the query string, but I ran into an 80-character length limitation that SiteMinder has with the RelayState. So, a cookie-based approach will be used instead. The flow is as follows:

  1. The user accesses a protected resource without a SiteMinder session
  2. SiteMinder redirects the user to the custom FCC
  3. The custom FCC caches the TARGET into a cookie
  4. The custom FCC redirects the user to either the authn URL or the IdP URL
  5. The user is authenticated by the IdP and the assertion is posted back to SiteMinder
  6. The user is redirected to the SAML 2.0 Template authentication scheme target, which is the redirection page described above
  7. The redirection page reads the cookie, deletes it and then redirects the user back to the originally requested resource

Sample code for the interim FCC:

<script language="JavaScript" type="text/javascript">
var target = "$$target$$";
var HostServer = "https://server.with.redirection.page

/ //Use a JavaScript method to create the SMORIGTARGET cookie

Sample code for the redirection page (the code below is ASP, but any language will work):

<script language="JavaScript" type="text/javascript">
//Use JavaScript to get SMORIGTARGET Cookie
var OrigTarget = getCookie("SMORIGTARGET");

Protecting a Resource Allowing Both Forms Authentication and SAML 2.0 Authentication

The mechanism for allowing this is similar to the interim FCC approach specified above. The difference is that the interim FCC allows the user to directly enter credentials and only performs the federation redirect based upon certain logic (e.g. a cookie that indicates the use wants to leverage federation).

Refer to the relevant SiteMinder documentation for detailed steps on how to configure federation, authentication schemes and other SiteMinder-related configuration.

3 Building Blocks for Managing Cloud Applications

header Now that my webinar with Mike Donaldson and Lisa Grady is over I wanted to post up some additional information and also a video of the working demo. Thanks to Ping Identity and Radiant Logic for working with us on this demo.


As a recap of the demo scenario, our theoretical company, MyComany, is looking to leverage cloud-based services and their strategy is to continue to migrate a significant amout of infrastructure to the cloud. The first application they have migrated is Salesforce CRM for Sales management. After that, they plan on expanding into Google Apps, a hosted provider for time and expense submission, HR, etc. The company has an internal Enterprise Directory (LDAP) which stores Employee profile information and the sales region and list of accounts for a Sales Rep is stored in Salesforce CRM. Since not all employees have access to Salesforce, there is also an internal portal that employees use to find Sales Rep and customer information.

Since they started using Salesforce, they are noticing these main problems:

  1. Managing the provisioning/de-provisioning of internal users in Salesforce is a time consuming manual process and in one case an terminated employee was not de-provisioned correctly and wound up getting access to information they should not have been able to access as a non-employee.
  2. They have a high number of password management issues since users have a separate account in Salesforce.
  3. Certain pieces of information are managed about salespeople and accounts in Salesforce and are not visible through the portal. This limited access to information required for the distribution of new leads and to contact the correct Sales Rep in case of a customer issue.

So, they want a solution that provides the following benefits:

  1. Automates the provisioning and de-provision of users in Salesforce based upon membership in a group in LDAP
  2. Centralized view of internal user information with attributes coming from LDAP and Salesforce that can be surfaced through the portal
  3. Centralized view of customer information that shows both the information coming from Salesforce but also includes the information from the accounts payable database for the complete view of the customer
  4. Single Sign-on into Salesforce from the MyCompany Portal


  • Ping Identity PingFederate for provisioning and de-provisioning of users based upon group membership in the salesforce group in VDS
  • Ping Identity PingFederate for Internet SSO using VDS as the LDAP directory for the Identity Provider (IdP) and Salesforce as the Service Provider (SP) using SAML


  • Radiant Logic VDS Context Edition to create a single view of the employee information with cached attributes coming from LDAP and Salesforce
  • Radiant Logic VDS Context Edition to create a single view of the customer with cached attributes coming from the Salesforce Users and Accounts tables


For larger images, please see the slides from the presentation included below.


Once implemented, this simplified their environment and provided greater flexibility as they looked to expand into the other cloud services, minimized trouble tickets for Salesforce password resets and improved internal access to information.


The following video shows the working demo which addresses the requirements above. This is just the starting point of what will eventually become a centralized hub for access to critical user and contextual data across repositories both internal to your company and also across cloud services outside of your firewall.

3 Building Blocks for Managing Cloud Applications - Video Demo

Webinar Recording:

A recording of the webinar is available on Ping Identity website. Note that registration is required.

View the Replay

I have also uploaded the slides to SlideShare so that you can more easily see the larger images:

I would love to hear what you have to say about this concept. Special thanks to Ian Barnett (Ping Identity) and Prashanth Godey (Radiant Logic) for helping to get this demo set up.

Thanks, Todd

Why RockYou Should Have Federated Identities

In case you haven't seen the news, RockYou's users have become casualties in the latest web privacy breach. TechCrunch detailed RockYou's numerous transgressions here:

Earlier today news spread that social application site RockYouhad suffered a data breached that resulted in the exposure of over 32 Million user accounts. To compound the severity of the security breach, it was found that RockYou are storing all user account data in plain text in their database, exposing all that information to attackers. RockYou have yet to inform users of the breach, and their blog is eerily silent – but the details of the security breach are going from bad to worse.

32 million users. If you thought you were having a bad day, imagine what RockYou's leadership team is dealing with. Winning back the trust of a single user can be challenging, let alone the other 31,999,999.

RockYou has some 'splaining to do

Of course it's easy to pile on RockYou for the many boneheaded decisions that led to this breach. Users can't protect themselves if they don't have the proper tools, and the act of promoting the use of simple passwords by practicing non-existent password policies is a virtual invitation to hackers. Sadly enough, even stricter policies could not have saved RockYou since they elected to store passwords in the clear. In the applications world this is the ultimate rookie mistake, and it's difficult to imagine a company like RockYou making it.

Unfortunately the impact of RockYou's mistakes has ripple effects for other social network partners. As TechCrunch revealed, RockYou collected user credentials for integrated sites such as Facebook and MySpace and stored them (in clear text) in their database. So if you're one of the unfortunate RockYou users who submitted login credentials for both those networks, you have more than just your RockYou data to worry about.

So besides following through on their promise and not storing the data to begin with, what could RockYou have done to work around the issue of exposing login credentials from their partner networks to hackers? That's easy: FEDERATE! Federated authentication is a protocol that allows companies to trust incoming login requests from known sources, thereby eliminating the need for storing a separate login and password. Simply stated, federation is single sign-on deployed across the internet. This means user identities are more portable, the user experience is more seamless, and the login data is more secure since it does not need to be stored in multiple locations.

Facebook Connect login option

Sounds complicated, right? But the reality is you're probably already using forms of federation in your every day web experience. Authentication services like Facebook Connect and Twitter's oAuth are examples of federation in action. Why expose yourself to more risk by storing credentials when you can simply piggyback on what your partner is already doing?

Of course, the value of federation isn't limited to social networks. Large enterprises like CA are using federated security models to drive partnerships and other business relationships. Our own Todd Clayton has described a vision for a Federation Oriented Architecture where the principles of identity federation are applied other data. There is no doubt the need for identity federation is on the rise, and we expect to see plenty of work in this area in 2010.

Unfortunately hindsight cannot save RockYou from the embarrassment over this mess. The users who choose to stay with them can only hope they'll learn from their mistakes.