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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
