Hi,
It’'s my first post in your forum. I am newer to use openfire. I want to integrate Openfire with CAS Server for authentification and OpenLDAP.
Somebody Has already done this integration? If yes, How? I will very glad for every feedback.
I am also opening for any track!
Thanks in advance.
Any relpy??
Please help me.
LDAP Guide
Ok thanks.
In fact, I have integrate CAS and OpenLDAP. Also Openfire and OpenLDAP. But, it is remain to casiefied OpenFIre ie to integrate Openfire and CAS?
Is it possible or not? If yes, how to or where I could find documentation?
Thanks in advance.
This is actually the first I’‘ve heard of CAS, so I don’'t really know what advantages it offers over LDAP alone. I found a CAS-LDAP guide that you may have seen already.
From what I can tell, CAS only works for web applications, so I don’'t think it applies to Spark. Configuration Openfire to authenticate directly against the LDAP server seems to make the most sense. Otherwise, I think this is more a question for the CAS people.
Hi,
I am also looking to integrate OpenFire with CAS. I have some ideas on how this can be done, but I am only beginning the process. I would also be interested if anyone else has had experience with this, but judging from the lack of response so far to this thread, I am guessing we are pioneers in this area.
Just to be clear for those OpenFire gurus who may not be familiar with CAS, it is a single sign-on solution. Its advantage over pure LDAP authentication is that it allows a user to authenticate a single time and get access to multiple applications using the same credentials. It is primarily designed to be used with web applications, but integration with a not-purely-web-based application like a Java or Flex chat client should be possible provided the client is launched from the browser, giving it access to browser resources, in particular cookies.
Basically, each application is CAS-ified (to use the CAS terminology) so that when a user accesses the application as a not yet authenticated user, they are redirected to the CAS portal. CAS collects the username and password and authenticates the user. It returns a cookie with a CAS ticket in it to the browser and then redirects the browser back to the original application. When the CAS-ified application sees the cookie, it contacts the CAS server to validate the ticket and retrieves the username associated with the ticket. Therefore, the user is logged in without seeing any application-specific login page. When a user visits subsequent apps that are also CAS-ified, they are automatically logged in similarly, again without seeing yet another login page.
LDAP can still be used as the back-end authentication source. CAS uses ACEGI Security for Spring under the covers and ACEGI provides adapters out-of-the-box for doing the authentication against an LDAP server.
Since all one needs to log into a CAS-ified application is a way to indicate to the application that it is a CAS login (e.g. a special username) and the CAS ticket (which can be obtained from the cookie and can be used in lieu of the password), it should be possible to CAS-ify both the OpenFire server and any OpenFire client that is launched from the browser (though access to the client source code is likely required).
Here are my initial thoughts to get the ball rolling.
I would be happy to hear any opinions or just discuss this further with others who are interested. If several people need this, why not make it a collective effort and share the fruits of our labors.
CAS-ifying the client should be a matter of retrieving the CAS ticket from the cookie stored in the browser. The name of the cookie and the form of the ticket are well documented so this should be fairly easy, I think. When connecting to the OpenFire server, a special username (not valid as an OpenFire user) could be used to show that this is a CAS login. The ticket would be passed in place of the password. The only prerequisite is that you must have logged into CAS prior to connecting or there will be no cookie to retrieve. The client should probably be written to return an authentication error in the event the cookie is not found … or possibly to do a client-side redirect to the CAS portal to let the user log in. There isn’'t any clean way I can come up with of to do a server-side redirect to the CAS Portal login page since the server in this case is not a web server.
My plan is to provide a minimal, custom Flex client using the XIFF API. Since I will be writing the client, it should be relatively straightforward to do the above. CAS-ifying the Spark client would require making changes to the Spark source as nearly as I can tell. I don’'t see any non-intrusive way to CAS-fiy it.
On the server side, OpenFire kindly provides an interface that can be implemented to provide a custom module for authentication. This seems the best place to start. Essentially, the custom module could either check for a special username to determine whether to authenticate against CAS or assume all logins are via CAS. Either way, the next step is to take the ticket (from the password field) and call CAS (a simple https service) to validate the ticket. So far I have run into one problem that I am still trying to find a solution to …
The current interface for authentication assumes, as nearly as I can tell, that the username field passed in is in fact the actual username … which is I suppose reasonable. However, in this case, the username is not known until after CAS validates the ticket … the initial username passed by the client is only a placeholder. It looks like by the time this happens, it may be too late to inform OpenFire of what the real username is. I suppose one possibility would be to modify the OpenFire source rather than just creating a custom authentication adapter, but this is more intrusive than I would like. I am still looking for a way around this issue. But it is possible I have just missed something … as I said, I am only just beginning this process.
If the server authentication mechanism assumes all logins are via CAS, then I could pass the actual username instead of a placeholder indicating a CAS login. But this requires me to remember the username on the client. And since the user only types in the username on the CAS portal, I think this would require me to modify CAS to return a cookie with the username as well as the CAS ticket. So I would be trading work on the OpenFire side for more work on the CAS side. Also, I’‘m not convinced yet that there isn’'t some security disadvantage to saving the username in a cookie on the browser.
I hope this has given some food for thought. I would be very interested in hearing others view or thoughts.
Thanks.
Bill Bailey
Senior Developer / DBA
Northland, A Church Distributed
The way you describe it, it sounds like CAS may be using GSSAPI, is that true?
I only know a little about GSSAPI, but as far as I understand, CAS does not directly utilize or implement this API.
The protocol followed and the API’‘s available are proprietary to CAS, I believe. But CAS does support integration with SPNEGO which is, as I understand it, a windows based implementation of GSSAPI. Also, it’‘s possible that there is also integration available with kerberos, but I haven’'t been able to tell for certain. In any case, the goals and the approach seem very similar between the two, at least based on my limited knowledge at this point.
For anyone interested in more details than I am able to provide, CAS can be found at http://www.ja-sig.org.
Just on a side note, it seems to me that out-of-the-box integration with single sign-on solutions like CAS (and others like kerberos, SPNEGO, etc.) would be a very desirable feature in OpenFire (or any application for that matter). I would certainly be willing to donate anything I come up with to the open source effort, but I could use help from people who know a lot more than me about OpenFire. I will probably be begging for help in the CAS mailing lists, too. Also, the more people contribute, the more likely this will be an open and reusable answer and not just a one-time kludge to meet my needs only.
Thanks again for the interest.
Bill
I think your best bet is going to be to get CAS to work with SPENGO and/or GSSAPI, since there are already good implementations of these protocols out there for Java. Otherwise you are looking at wanting to write a java SaslServer object that implements the CAS protocol.
Maybe I am missing something, but I don’‘t see anything indicating that Openfire supports GSSAPI or SPNEGO out of the box either. So I’'m not sure how using either of these simplifies my task.
It appears to me that the authentication adapters just implement an interface, which on first glance does not seem too complicated. I agree that implementing the CAS protocol from scratch might not be the best idea, but I am hoping I can reuse some of the Java code already available in existing CAS clients or from ACEGI which already implements the CAS protocol internally.
If there is an easier way I am more than happy to entertain any suggestions, but I am still not completely clear on how I would use either GSSAPI or SPNEGO to make my job easier. Can you elaborate?
Thanks.
Bill Bailey
Senior Developer / DBA
Northland, A Church Distributed
Openfire supports GSSAPI out of the box at this point, but the documentation for setting it up is not fully together. SPENGO support is available from some external patches (which Im hoping to get incorporated into Openfire directly at some point).
There are a few reasons why implementing a GSSAPI bridge to CAS would be useful. GSSAPI was designed to be a generic protocol for passing authentication/authorization tokens around. Kerberos is the primary user of it, but occationally other users of it show up. Perhaps the biggest roadblock is the GSSAPI SASL implementation was written with Kerberos specifically in mind, so there will be some roadblocks there. Openfire is also not the only application that has GSSAPI support. So if you were to implement a CAS-GSSAPI bridge of some sort, then other applications could take immediate advantage of it (many mail servers, cvs, other jabber servers, ssh, and a whole lot more).
But, implementing such a thing would not be easy or quick. If you are looking for a quicker solution, consider writing a Java SaslServer and SaslClient implementation of CAS. The problem there is there is no IANA registration (http://www.iana.org/assignments/sasl-mechanisms) for a CAS SASL implementation, so you would be writing your own protocol essentially. But I bet you could take cues from the GSSAPI implementation.
I think any route you choose will be a significant amount of work though. If you are up for the challenge, keep me in on the loop. Ive been doing a lot of work lately on getting the authentication and authorization code in Openfire cleaned up, so if you need some change in that arena just let me know.
Thanks for the information.
I will look into the GSSAPI and SPNEGO options to see if CAS supports them in a way that can work for me. Since you seem to be knowledgable in the area of authentication, users, etc, would it be too much to ask you to also take a look at another forum posting I made which I have not yet received any responses on? It is on the related issue of using external providers for authentication, users, and groups.
It the following entry …
http://www.igniterealtime.org/forum/thread.jspa?messageID=147902𤆾
Thanks.
Bill