Single Sign On

What I was trying to say is; you have to provide some sort of indication of your application requirements before you start to consider a solution for SSO. I can provide you with links, so can www.google.com, but the information will be meaningless without understanding your application.

* Does your existing application assume that users and their privileges are provisioned in its local database?

* Do you have a legacy security architecture to interoperate with?

* Do you have proprietary client/server messaging protocols to consider?

* Do you deploy your application across various operating systems?

It all starts with your applications' requirements. There is no SSO silver bullet, only enabling technologies which will vary in mileage depending on your needs.

refactor77a at 2007-7-15 5:04:22 >

There may be other ways, but the closest thing to an out-of-the-box solution I found was the AuthenticationFilter servlet filter in the jcifs-ext package on sourceforge (http://sourceforge.net/projects/jcifs-ext/). The limitation with that is it gets you authentication, but not authorization (no role-priv lookup). That can be done via LDAP though, or you can try to actually parse the role/group membership in the kerberos ticket from AD called the PAC (non-trivial and not documented).

I implemented a solution by starting with the securityfilter project (http://sourceforge.net/projects/securityfilter/), adding the core parts of jcifs-ext, and then doing role/group lookup with an existing LDAP framework I had.

ericsworda at 2007-7-15 5:04:22 >