Difference between SSO (Single Sign On) and Identity Federation

There is a lot of confusion on the net between SSO and Identity Federation. Both concepts may look the same to the end users, but they are different. Today many authentication products implement both, further increasing the confusion. Here I’ll try to explain the difference as I see it.

Identify Federation (sometimes referred as Federation or Federated Identity) allows the end users to use the same set of credentials to obtain access to multiple resources. This gives an advantage to the software systems that utilize Identify Federation, both from security and usability perspective – the end users do not have to maintain multiple sets of credentials. Yet, the users have to provide their credentials to each one of the participating resources. Typically Identify Federation system are based on single credentials store, but other implementation methods (for example, password synchronization) may also be used.

SSO (Single Sign On) allows the end users to provide their credentials once and obtain access to multiple resources. The key point of the concept is that the users are not prompted for their credentials anew on access to participating resources until the active session is terminated. The participating resources are typically related, but still remain independent. Specifically, each system may have own authorization system, providing system-specific roles to the end users. The practical implementation of the supporting software system remains out of scope for the concept definition.

CA SiteMinder’s “DisallowForceLogin” registry key demystified

Warning: This page deals with one of the vague Policy Server flags and assumes certain level of familiarity with the dark soul of CA SiteMinder.

Is is pretty hard to understand the meaning of the DisallowForceLogin registry key for SiteMinder Policy Server from the official documentation, even when you have plenty of time and manuals. This page pretends to summarize all that you may need to know about it, should you have to deal with this functionality some day.

History and Functionality

In a pre-R6 environment, when a user submits a password change request that contains an invalid current password, the Password Change Information screen appears with a message stating that the old password is incorrect. The user can provide the correct credential and change the password.

In R6 and R12, the Policy Server redirects the user to the login screen without the message (that is, ”forces login screen”). Enabling the DisallowForceLogin registry key allows the old behavior in a new environment. When enabled, the Policy Server properly redirects users who have submitted a password change request that contains an invalid current password to the Password Change Information screen. This screen displays the invalid current password message. When disabled, the Policy Server redirects users to:

  • The login page that does not display the invalid current password message. This redirect occurs if an On-Auth-Reject-Redirect response is not bound to the policy configured with the user directory.
  • The URL associated with the On-Auth-Reject-Redirect response bound to the policy configured with the user directory

According to R6SP5 README, there are three cases affected by the DisallowForceLogin value:

  • Force password change or password expired.
  • Self Password change.
  • Optional password change.

Continue reading “CA SiteMinder’s “DisallowForceLogin” registry key demystified”

Recipe: email delivery system for automatic tests

Some time ago I was asked to help in implementing an automatic test for one of the application flows. In this flow the system under test was sending emails with dynamic content to the end user, and the test had to verify the content of those emails.

The testing system had two basic requirements:

  1. The email address to send those emails should be unique, since several tests of this kind will run simultaneously.
  2. The retrieval of those emails should be as simple as possible, without any dependency on specific programming languages or libraries.

To make the long story short – the solution that we implemented consists of the ‘sendmail’ daemon with specially crafted aliases file, shell script to parse incoming email and store it in the own file by username, ‘httpd’ daemon to expose the files with emails over HTTP and a cron script to clean those files; all those based on standard RHEL 5.5 distribution.  Continue reading “Recipe: email delivery system for automatic tests”

IBM Tivoli Access Manager for e-business and WebSEAL Resources

After posting another WebSEAL HOWTO recently, I feel it is the right time to post my collection of WebSEAL-related resources and forget about the WebSEAL for a while.

IBM Tivoli Access Manager (TAM) for e-business is positioned by IBM as an end-to-end security solution for e-business, focused on providing robust, policy-based security to a corporate web environment. The web security components of TAMeb are WebSEAL (reverse proxy web server that performs authentication and authorizations; typically used for DMZ external access to backend content servers) and Plug-in for Web Servers (plug-in that secures web servers; typically used for internal access). Continue reading “IBM Tivoli Access Manager for e-business and WebSEAL Resources”

Gmail App for iOS – Pros and Cons

[ This mini-review was originally written in mid-November 2011, when Gmail App for iOS was back to AppStore, and published on Google+. Today Google released an update for Google Sync (ability to easily delete messages instead of archive them – something I was missing in the native email client), so I recalled this text and reposted it here also. ]

I decided to try the new Gmail App over this weekend. Here is a short summary:

Pros:
1. The Gmail App has Gmail-style threaded view that I really miss in native iOS client. Also, the UI look and feel is synced with the new style of the browser version of Gmail.
2. The Gmail App allows me to do a clear separation between corporate and private mailboxes – work Exchange goes to native client, Gmail – well, to Gmail. For me, it is very convenient to see if it is personal of work-related email before I run to check it out. Also, with this separation I can disable notification sounds on any specific email account (the work one, i my case).
3. Other reviews report that search here is much better. I had no chance to test this on my own today, but native search was sometimes… say, frustrating.

Cons:
1. The main concern about Gmail App is that it is not fully integrated in all the applications on iOS like the native client – and there is no hope for such integration. Of course, you can compose emails using native address book or browse for picture attachments, but other apps the utilize sharing via default email client (for example, Genius Scan) obviously are out of scope here.
2. It seems that Gmail App is not so fast in getting emails as Gmail account defined in the native client via Google Sync with Push. I have no reliable idea what is the reason for this behavior…
3. There are no modern-style banner notifications in the Gmail App for some reason. Yet, I hope this is something to be added in the future versions.

As you may see, there are both pros and cons of using new Gmail App instead of the native email client, and I’m still not sure if it will survive on my iPhone. But I will test it for few more days…

Update (January 2012): Still using Gmail App. It is definitely slower that native client, but the threaded view and the ability to easily archive, delete and star messages keeps it alive for me.