views:

33

answers:

1

Scenario:

  1. We sell J2EE(JBoss+SpringSecurity) software to large corporation which mostly use ActiveDirectory
  2. Our J2EE(JBoss) software can be hooked up to ActiveDirectory, however it requires Roles addition into ActiveDirectory i.e. cn=esp_administrator,cn=Roles,o=company,o=com
  3. As per my understanding, JBoss will need an account to "bind" to ActiveDirectory to do the search i.e. cn=admin,cn=Users,o=company,o=com
  4. Users still need to login to our J2EE application manually (not single sign-on)
  5. Say our J2EE app http://j2ee-webapp/ and one of the company portal is at http://intranet-portal/ say using Atlassian Jira

How can I implement single sign on with this setup? One thing comes to mind is to read cookies from http://intranet-portal/, but this only works if our J2EE webapp is a sub-domain of http://intranet-portal, i.e http://intranet-portal/j2ee-webapp/


I've read the following QA

http://stackoverflow.com/questions/2567919/single-sign-on-for-a-web-app

http://stackoverflow.com/questions/1043111/transparent-user-session-over-several-sites-single-sign-on-single-sign-off

I don't think the customers want us to install Shibboleth IDProvider just for single sign on.

Other than a "Remember me" option, what other choice do I have?

+1  A: 

You could indeed use Shibboleth (or perhaps OpenSSO). This can be quite complex and will need to be deployed for all the websites (Service Providers) that will be under the scope of this SSO. It's specifically designed for SSO authentication and authorization that do not necessarily belong to the same site. If your customers want SSO in an environment that's not too tightly coupled, they'll need this sort of technology. (Note that the most difficult part of implementing Shibboleth isn't so much the installation of the SP or IdP software, but rather establishing the policies around attribute release and authorization: more about administration and politics than a technical problem).

If the client machines from which your customers are going to connect are also under their control (for example, if they're all Windows desktops that the company can configure), you could look at SPNEGO. This can be made to work from Windows/Linux/OSX clients using IE/Firefox (at least), but you'd need to configure the clients to point to the Active Directory server (as a Kerberos KDC). This may be confusing if users have to do it on their own machine.

While the SPNEGO solution may be easier if you can control the configuration of the client machines, the Shibboleth/OpenSSO solution will be more flexible in that respect (and the Shibboleth IdP could use SPNEGO as an authentication mechanism, if you want it all).

Bruno