Leonis proudly presents: Single Sign On for Question2Answer
We are big fans of Question2Answer, as it is a wonderful piece of software for handling Q&A written in PHP. Think of it as StackOverflow On Premise, with your own design, your own user database, centered around your services. You can find it here.
There are a couple of competitors on the market (refer to this entry at Meta StackExchange), some of them are very promising, especially LampCMS and Shapado as they make use of the great NoSQL Database MongoDB. This is exactly of our taste, since we find scaling to be crucial and Shapado meets our second taste: Ruby. The remaining Q&A systems provided in this StackExchange post are good in their respective domain, but do not apply to us (‘hosted service’ for instance, refer to the last section of this post), have complicated interfaces and APIs or there’s not enough development. Nonetheless, we pick Question2Answer.
The reasons why we love Question2Answer
- Design counts. Even Guy Kawasaki is very strict about this topic (Watch his videos!). We want to customise the layout, slam Bootstrap onto it, add Glyphicons and FontAwesome wherever we want them to show up. Seriously, we want to make use of a site wide design. ‘Branding’ is the keyword.
- We select our software carefully. We want to make use of software and contribute to it. We do not like to face dead ends, so a vital user base is of high importance.
- We love plugins. Good software is well documented and gives us the opportunity to either install plugins or write them ourselves whenever needed.
- PHP is just fine. As long as the code is written properly and covers our security needs.
- We love software that does not break when upgrading.
- We love flexible Software. Integrate external users? Integrate it into your CMS like Drupal (or even easier Wordpress)? Just do it!
So, from a technological or let’s say engineering perspective, Question2Answer performs really well and we find it suitable to contribute to. There are many users out there working hard on sharing designs and plugins, so we made the decision to give something back to the community.
What does our plugin do?
It makes the life of admins and users more convenient: It provides an ‘interface’ to a CAS server (Central Authentication Service, originally developed by the Yale University), which authenticates users against LDAP directories, thus making Single Sign On for registered users possible.
Use Case 1: A company has a website where it showcases its products, services, investor relations and team members. The users of this website authenticate against an LDAP directory, the staff members against another directory. Both of them cooperate in building a knowledge base around the company’s products and services. Now, there should not be any kind of barrier for the customers for entering the Q&A section of the website. They fill in their credentials once and gain access to the restricted areas of the website and the Q&A system at once.
Use Case 2 (also known as The Leonis Use Case): Our DevTeam works with another team of developers and the people of the Finance team. The team members gain access to our services via a Drupal instance that serves as an entry point. There they do collaborative development at our GitLab, track their issues with Redmine, attach files to the repositories via ownCloud, add code via Codiad when on leave and discuss development rapidly via Question2Answer. One button click – our user is authenticated against the LDAP service, his or her data instantly being created. No more filling in email, full name, group and so on.
Why we decided to go for CAS.
We made the decision for using CAS as the SSO provider due to the following reasons:
- Scalability is crucial, so we need a concept with orientation towards enterprises.
- Flexibility: We do not want to rely on a solution provided by high-level software like CMS-centered solutions (e.g. Drupal SSO server)
- Configurability: The average SysAdmin should be able to configure and customise the underlying software easily. This requires well-known runtimes and frameworks. CAS can be implemented with software written in Java or Ruby. (See a couple of paragraphs below.)
- It should be widely recognised as being stable and reliable. We do not want to rely on low-level software which’s upgrades make it necessary to rewrite plugins from scratch.
- Obviously, popular software should be capable of making use of the SSO service.
We have compared various SSO services but selected CAS as the way to go, since it covers all our needs stated above. There are well-documented framworks for getting a CAS server instance up and running, we decided to make use of RubyCAS on Apache with Passenger. The maintainers of CAS even deliver phpCAS and serve a great documentation at their CAS Wiki.
An admin who has just a couple of weeks of experience with Ruby therefore can bring an SSO server up and running within a couple of minutes. We will also share a proper documentation about how to set up a RubyCAS instance with a startup script.
Stop it already, where do I find the plugin?
You can find our plugin at our public repository at GitHub.
Of course the documentation is still lacking, but we are working on it and will do a proper description within the next couple of days.
Alright, so what about the issue with ‘hosted’?
Uhm, we’re doing SaaS development? We configure complex server and cluster systems for clients? We do financial engineering for clients and partners? All of these tasks involve very, very sensitive data. By no means we’d have our data handled by any service provider whom we do not know – especially when their servers are not located in the EU, Japan or Singapore. We have a very strict policy concerning information management, so we would not even think about hosted services.