That does shed additionaly light on it, and unfortunately, you are right -- your environment is not conducive to Kerberos & GSSAPI.
It sounds like your best bet is to write a custom OpenFire authentication module, taking the UserName & ProxyTicket as credentials and validating them. Just as an aside -- I've been toying with the idea of using the nifty Net::LDAP::Server [1] Perl module to write an LDAP server that authenticates a simple bind when supplied a UserName as a DN and a Proxy Ticket as a password (perhaps with the Service provided as the search base) by performing ticket validation. I wonder if this kind of approach would be simpler, allowing you to use OpenFire's stock LDAP module. Any thoughts from anyone on this approach? [1]http://search.cpan.org/~aar/Net-LDAP-Server-0.3/lib/Net/LDAP/Server.pm -Matt -----Original Message----- From: Bill Bailey [mailto:[EMAIL PROTECTED] Sent: Thu 2007-05-31 15:21 To: Smith, Matt; Yale CAS mailing list Subject: RE: CAS + OpenFire Matt, Thanks for the info. I appreciate your help. But if I understand things correctly, I don't think this approach will work for us. Your explanation clarified a few things about SPNEGO and GSSAPI that were fuzzy for me and helped me to see things a bit clearer, though. We have a couple of requirements that I suspect may be different from yours. The first difference and probably the more significant is that we do not own all of the desktops on which the applications will run. We are a church and we will be making this application available to our congregation and anyone on the internet who wishes to participate. Therefore, we have little control what mechanisms are used to log into the desktop. In fact, many of our users will be using home computers that don't require them to log into the desktop at all. The only thing they 'have to' log into is our web application. As a corollary to the first issue, we also cannot require that anything be installed on the client desktop other than the rather ubiquitous plug-ins like Flash. Requiring them to download and install 'thick' clients is not something we want to do because some people might be reluctant to do so. So we are limited to strictly web-browser clients like Flex or Java. And since even the Java plug-in requires a more elaborate install than the casual user is often comfortable with, we had decided on Flex and the XIFF API. Only the Flash Plug-In, albeit the new Flash 9 one, are required for this approach. The second issue is that we need to embed customized chat client in parts of our application. We do not wish in all cases to expose an entire client with all of its features and we may want to make other customizations that would make it difficult to use an existing client like GAIM. Assuming the client were written in Flash, Flex or Java, and assuming we had access to source code, I suppose we could use an existing client as a starting point, but I think that is a lot of assuming and would probably still be quite a bit of work, possibly more than just writing a simple, custom chat client w/ XIFF. If I totally missed the point of anything you were saying, please feel free to set me straight. I appreciate the input and if you have any other ideas feel free to share those as well. Thanks a lot. Bill Bailey Senior Developer / DBA Northland, A Church Distributed -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Smith, Matt Sent: Thursday, May 31, 2007 2:51 PM To: Yale CAS mailing list Subject: RE: CAS + OpenFire We are a CAS shop, playing with OpenFire & GSSAPI (Kerberos). Here is our approach: * CAS will be used for Web Application, Kerberos for thick applications. * We have MIT Kerberos running, and CAS authenticates (simple ID/Password) against it. All modern Windows and *nix (including OSX) have GSSAPI/Kerberos capabilities. Check out MIT's Kerberos for Windows (KfW) for enhanced functionality. * We will be implementing SPNEGO authentication to CAS at some point. What this means is that I will obtain a Kerberos ticket (TGT) at desktop login, a session ticket obtained using that TGT will be passed as a GSSAPI token from my browser to the CAS server (using SPNEGO/HTTP), and CAS will issue a cookie (TGC). The TGC will then be used to generate service tickets that get me access to CAS-ified web apps. No authentication other than desktop login is needed for this. *OpenFire will be accessed using SASL/GSSAPI enabled clients (like GAIM/Pidgin) seamlessly, using the same Kerberos TGT as above. No authentication other than desktop login is needed for this. The point of this story is that we are not going to try to mangle CAS for OpenFire authentication, but rather OpenFire will directly use the same Kerberos backend as CAS. HTH, -Matt On Thu, 2007-05-31 at 14:16 -0400, Bill Bailey wrote: > Jason or Scott, > > > > One of the OpenFire developers suggested I look into SPNEGO or GSSAPI > as a possible means of integration since he says there is integration > already available for OpenFire using these technologies. I have found > several references to an SPNEGO adapter for CAS, but I don't see > anything on GSSAPI. I think SPNEGO is an implementation of GSSAPI or > some part of it, but I am not terribly familiar with either. Can you > tell me what sort of support is available for either of these > authentication methods? Also, am I right in thinking SPNEGO is a > Windows-only implementation? I also have a need to support Mac users > and possibly even a few Linux users so a Windows-only solution > probably won't work for me. > > > > Thanks. > > > Bill Bailey > > Senior Developer / DBA > > Northland, A Church Distributed > > > > > ______________________________________________________________________ > From:[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Jason Shao > Sent: Thursday, May 24, 2007 4:23 PM > To: Yale CAS mailing list > Subject: Re: CAS + OpenFire > > > > > Hey Bill, > > > > > > Openfire looks cool -- I'd love to hear how it works out for you. > Thoughts below. > > > > > > On May 23, 2007, at 9:56 AM, Bill Bailey wrote: > > > > There are a couple of things I still have questions about. > > > > First, although OpenFire allows the authentication to be customized, > > it appears that it still expects the username to be passed in as > > part of the login. I do not see any way to inform OpenFire of the > > username AFTER the authentication occurs and if I understand CAS > > correctly you do not know the actual username until the ticket is > > validated. > > > > > > How hard would it be to customize CAS to return the username to the > > browser (e.g. in the form of another cookie) so that the client can > > pass in the real username rather than a placeholder or null? Is > > there some security reason that is not obvious to me that this > > should not be done? > > > > > > An alternative approach would be to have your FLEX webapp validate the > proxyticket, get the NetID, and then obtain a proxy ticket. You could > then pass the username and the proxy ticket directly to openfire. This > has the advantage that you could then restrict Openfire to only accept > CAS auth from that webapp (if so desired) -- or all the other magic > that proxy chains let you accomplish. > > > > Second, when I write the custom authentication module, should it be as > simple as just calling the ServiceValidate service and getting either > an error response or a success response (with username)? What is the > best Java client to look at for an example of what I need to do? Keep > in mind that the chat server is not a web server so I don't think > (tell me if I'm wrong) any of the existing Java clients can be use > as-is. > > > I know one of Scott's goals in the JA-SIG CAS Java Client 3.0 rewrite > was improved modularity -- it sounds like this would be a great > use-case for the new code. > > > > > > Scott? > > > > > > Jason > > > > > -- > > > > > > Jason Shao > > > Application Developer > > > Office of Instructional & Research Technology > > > Rutgers University > > > v. 732-445-8726 | f. 732-445-5539 | [EMAIL PROTECTED] > > > > > > > > _______________________________________________ > Yale CAS mailing list > [email protected] > http://tp.its.yale.edu/mailman/listinfo/cas -- Matthew J. Smith <[EMAIL PROTECTED]> University of Connecticut UITS _______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
