5

single sign-on (SSO) for web applications (used through a browser) is well-documented and established. Establishing SSO for Rich Clients is harder, and is usually suggested on the basis of Kerberos tickets, in particular using a Windows login towards an ActiveDirectory in a domain.

However, I'm looking for a more generic solution for the following: I need to establish "real" SSO (one identity for all applications, i.e. not just a password synchronization across applications), where on client's side (unmanaged computers, incl. non-Windows), the "end clients" are a Java application and a GTK+ application. Both communicate with their server counterparts using a HTTP-based protocol (say, WebServices over HTTPS). The clients and the server do not necessarily sit in the same LAN/Intranet, but the client can access the servers from the extranet. The server-side of all the applications sit in the same network area, and the SSO component can access the identity provider via LDAP.

My question is basically "how can I do that"? More specifically,

a) is there an agreed-upon mechanism for secure, protected client-side "sso session storage", as it is the case with SSO cookies for browser-accessed applications? Possibly something like emulating Kerberos (TGT?) or even directly re-using it even where no ActiveDirectory authentication has been performed on the client side?

b) are there any protocols/APIs/frameworks for the communication between rich clients and the other participants of SSO (as it is the case for cookies)?

c) are there any APIs/frameworks for pushing kerberos-like TGTs and session tickets over the network?

d) are there any example implementations / tutorials available which demonstrate how to perform rich-client SSO?

I understand that there are "fill-out" agents which learn to enter the credentials into the application dialogues on the client side. I'd rather not use such a "helper" if possible.

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

Thanks for comments, suggestions and answers!

MiKu

MiKu
  • 85
  • 1
  • 9

2 Answers2

1

Going with AD account IS the generic solution. Kerberos is ubiquitous. This is the only mechanism which will ask you for your credentials once and just once at logon time.

This is all feasable, you need:

  1. A KDC
  2. Correct DNS entries
  3. KDC accounts
  4. Correct SPN entries
  5. Client computers configured to talk to the KDC
  6. Java app using JAAS with JGSS to obtain service tickets
  7. GSS-API with your GTK+ app to obtain service tickets

What did you figure out yourself yet?

Michael-O
  • 18,123
  • 6
  • 55
  • 121
  • Thanks Michael-O, this sounds good if the client machine has an ActiveDirectory account (i.e. where a login produces a Kerberos ticket) - but I also want to cover the clients where this is not the case. In other words, I want to make no assumptions about the client, but I want to retrieve and "share" the TGT (e.g. a Kerberos ticket) in a dependable way. It is acceptable if this is done in a platform-specific way since Kerberos storage may be accessed differently. Any ways/techniques/APIs to do that? – MiKu Aug 19 '12 at 17:01
  • Are you in a managed intranet environment or on the Internet? – Michael-O Aug 19 '12 at 17:09
  • All the managed clients do have a Kerberos ticket. But I need to account for clients which have VPN access into the network - and are therefore neither managed, nor necessarily Windows. – MiKu Aug 19 '12 at 18:18
  • Well, I do not know how your communication protocol looks like but you can provide multiple auth option: GSS-API => Basic/Digest. The first one would be for domain users, the second one would check against a database. If you apply this scheme to HTTP, it would simply mean this: `WWW-Authenticate: Negotiate` and `WWW-Authenticate: Basic`. – Michael-O Aug 19 '12 at 18:29
0

Agreed with Michael that GSSAPI/Kerberos is what you want to use. I'll add that there’s a snag with Java, however: by default, JGSS uses its own GSSAPI and Kerberos implementations, written in Java in the JDK, and not the platform’s libraries. Thus, it doesn’t obey your existing configuration and doesn’t work like anything else (e.g. on Unix it doesn’t respect KRB5CCNAME or other environment variables you’re used to, can’t use the DNS to locate KDCs, has a different set of supported ciphers, etc.). It is also buggy and limited; it can’t follow referrals, for example.

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

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

There is no analogous option on Windows to use SSPI, however. This looks promising:

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

... but I haven’t gotten to addressing this issue yet.

Richard E. Silverman
  • 1,071
  • 8
  • 14