Geek Answers Handbook

Single sign-on for affluent clients ("Fat client") without logging into Windows

single sign-on (SSO) for web applications (used through a browser) is well documented and installed. Setting up SSOs for affluent customers is more difficult and is usually offered based on Kerberos tickets, in particular using the Windows login to ActiveDirectory in the domain.

However, I am looking for a more general solution for the following: I need to set a "real" SSO (one identifier for all applications, i.e. not only password synchronization in applications), where on the client side (unmanaged computers, including non-Windows), " end clients "are a Java application and a GTK + application. Both interact with their counterparts on the server using the HTTP protocol (say, WebServices over HTTPS). Clients and the server are not necessarily located on the same LAN / Intranet, but the client can access the servers from the extranet. The server side of all applications is in the same network area, and the SSO component can access the identity provider through LDAP.

My question is basically “how can I do this”? More specific,

a) is there a consistent mechanism for a secure secure client "sso-session storage", as with cookies cookies for SSO applications for applications that support the browser? Perhaps something like Kerberos emulation (TGT?) Or even directly reusing it even where ActiveDirectory authentication was not performed on the client side?

b) are there any protocols / APIs / frameworks for exchanging data between rich clients and other participants in SSO (as is the case with cookies)?

c) Are there any APIs / frameworks for push-like TGTs and session tickets over the network?

d) are there any examples of implementations / tutorials that demonstrate how to perform an SSO with a rich client?

I understand that there are "fill-out" agents that learn to enter credentials in client-side application dialogs. I would prefer not to use such an "assistant", if possible.

Also, if possible, I would like to use CAS, Shibboleth, and other open source components, where possible.

Thanks for the comments, suggestions and answers!

Miku

+4
source share
2 answers

Switching with an AD account is a common solution. Kerberos is ubiquitous. This is the only mechanism that will ask for your credentials once and once during login.

This is all possible, you need:

  • Kdc
  • Fix DNS Records
  • KDC Accounts
  • Valid SPN Records
  • Client computers configured to communicate with KDC
  • Java application using JAAS with JGSS to receive service tickets
  • GSS-API with your GTK + application for service tickets

What else have you found out?

+1
source

Agreed with Michael that GSSAPI / Kerberos is what you want to use. I will add that theres is a problem with Java: by default, JGSS uses its own implementations of GSSAPI and Kerberos, written in Java in the JDK, and not platform libraries. Thus, it does not obey your existing configuration and does not work like anything else (for example, on Unix, it does not respect KRB5CCNAME or other environment variables that you are used to, cannot use DNS to search for KDC, it has a different set of supported ciphers and etc.). It is also buggy and limited; he cannot follow referrals, for example.

On Unix platforms, you can tell JGSS to bypass the JDK code and use the external GSSAPI library by starting the JVM with

-Dsun.security.jgss.native=true -Dsun.security.jgss.lib=/path/to/libgssapi_krb5.so

On Windows, there is no similar option for using SSPI. This looks promising:

http://dblock.github.com/waffle/

... but I have not yet decided on this problem.

0
source

More articles:


All Articles