Web SSO vs. Enterprise SSO – What do I need?

So your organization has decided it needs to get a handle on managing the passwords for end users. A single sign on product is a great way to achieve that. Now the question becomes which product do I need? While the names may be similar, there is a big difference between Enterprise and Web SSO.

Enterprise SSO is designed (as the name implies) to provide single sign on to practically all the applications an end user would need. This includes web apps, Windows executables (thick clients), Java apps and mainframe/terminal emulator (greenscreen) apps. It works in a non-intrusive way by capturing the user ID and password for the application when the user logs in. The next time the application is launched, Enterprise ESSO will detect it and automatically enter the credentials on the user’s behalf and log them in. It can also be programmed to handle password changes (i.e. first time temporary passwords, 90 day password expiration). There is an executable installed on the end user’s desktop and profiles are created to recognize the login/password change screens for an application so the agent can respond to them. Since no changes are made to the applications, this provides a relatively quick and encompassing way to provide SSO to most apps a user would have.

Web SSO is a little different. Again as the name implies it focuses only on web based applications. Access policies are created in a central policy server that determine who can have access to various web applications. An enforcement agent (usually a reverse proxy web server or a web server plugin) is put in place to intercept web traffic. This agent will authenticate the user against a user repository (usually an LDAP directory) and then check the access rules in the policy server to see if the request should be passed on to the webserver. This provides a more integrated approach as access control is added in addition to SSO. It’s very useful in situations where you have a lot of in-house web application development. The developers don’t have to worry about building security into their applications; they can leverage the security framework of the web SSO product and just get the user ID passed to them in an HTTP header variable. This way the user just has one password to authenticate to the Web SSO product and the individual applications don’t have to store password information for the user. Once the user has a session with the Web SSO product they can access multiple sites without having to re-authenticate.

The two technologies can even be integrated together. The password used to log into the Web SSO product can be added to the Enterprise SSO credential cache so the user still only has one password to access all of their applications. So depending on the needs of your organization, you can determine which solution (or maybe both) would suit your single sign on needs.