Accessible link

.gitignore

@@ -1,12 +1,13 @@
 .svn
-config.yml
+/config/config.yml
 *.db
 *.sqlite3
 *.swp
 *~
 *.pidaproject
 *.log
 *.mo
+*.prod
 pkg
 ssl
 custom/*
@@ -18,4 +19,4 @@ resources/dev
 .bundle
 .vagrant
 Vagrantfile
-Gemfile.lock
+vendor/*

Dockerfile

@@ -0,0 +1,38 @@
+# We currently use Ruby 1.9.3 in prod, but bundle install is failing with that in dev.
+# We also can't use the newest ruby because it broke support for the syck gem in v2.2.
+FROM ruby:1.9
+
+#fix for jessie repo eol issues
+RUN echo "deb [check-valid-until=no] http://cdn-fastly.deb.debian.org/debian jessie main" > /etc/apt/sources.list.d/jessie.list
+RUN echo "deb [check-valid-until=no] http://archive.debian.org/debian jessie-backports main" > /etc/apt/sources.list.d/jessie-backports.list
+RUN sed -i '/deb http:\/\/deb.debian.org\/debian jessie-updates main/d' /etc/apt/sources.list
+
+# Note: gettext is installed to be able to use envsubst to inject config values
+RUN apt-get -o Acquire::Check-Valid-Until=false update -qq && apt-get install -y build-essential libpq-dev gettext vim
+
+# The rubycas Gemfile / gemspec doesn't specify a rails version since we use Apache Passenger modrails to run it in prod. 
+# Need this installed in the container to run the dev version.
+#RUN gem install rails -v 3.2
+
+# This is the version staging and prod run. This base image uses 1.9.0. 
+# Close enough that things should work, but update staging/prod if we have to get them in sync
+#RUN gem uninstall bundler 
+#RUN gem install bundler -v 1.7.3
+
+RUN mkdir /app
+WORKDIR /app
+# Note: in .dockerignore we exclude Gemfile.lock b/c we want bundle install to regenerate it for
+# this version of Ruby. It doesn't get copied over to the container if you have one laying around from a non-Docker build.
+COPY Gemfile /app/Gemfile
+COPY Gemfile.lock /app/Gemfile.lock
+COPY rubycas-server.gemspec /app/rubycas-server.gemspec
+
+# See this article for why we copy to /tmp
+# We have a runtime script to check this so we can deal
+# with changes properly when gem versions get updated.
+# https://nickjanetakis.com/blog/dealing-with-lock-files-when-using-ruby-node-and-elixir-with-docker
+RUN bundle install && cp Gemfile.lock /tmp
+
+# Do this after bundle install b/c if we do it before then changing any files
+# causes bundle install to be invalidated and run again on the next build 
+COPY . /app

Gemfile

@@ -1,6 +1,9 @@
 source "http://rubygems.org"
 gemspec
 
+#gem "mysql2"
+#gem "activerecord-mysql-adapter"
+gem "pg"
 
 # Gems for authenticators
 group :ldap do

Gemfile.lock

@@ -0,0 +1,127 @@
+PATH
+ remote: .
+ specs:
+ rubycas-server (1.1.3.pre)
+ activerecord (>= 2.3.12, < 4.0)
+ activesupport (>= 2.3.12, < 4.0)
+ crypt-isaac (~> 0.9.1)
+ pg (= 0.17.1)
+ sinatra (~> 1.0)
+ sinatra-r18n (~> 1.1.0)
+
+GEM
+ remote: http://rubygems.org/
+ specs:
+ activemodel (3.2.19)
+ activesupport (= 3.2.19)
+ builder (~> 3.0.0)
+ activerecord (3.2.19)
+ activemodel (= 3.2.19)
+ activesupport (= 3.2.19)
+ arel (~> 3.0.2)
+ tzinfo (~> 0.3.29)
+ activeresource (3.2.19)
+ activemodel (= 3.2.19)
+ activesupport (= 3.2.19)
+ activesupport (3.2.19)
+ i18n (~> 0.6, >= 0.6.4)
+ multi_json (~> 1.0)
+ addressable (2.3.6)
+ appraisal (0.4.1)
+ bundler
+ rake
+ arel (3.0.3)
+ builder (3.0.4)
+ capybara (1.1.2)
+ mime-types (>= 1.16)
+ nokogiri (>= 1.3.3)
+ rack (>= 1.0.0)
+ rack-test (>= 0.5.4)
+ selenium-webdriver (~> 2.0)
+ xpath (~> 0.1.4)
+ childprocess (0.5.3)
+ ffi (~> 1.0, >= 1.0.11)
+ crack (0.4.2)
+ safe_yaml (~> 1.0.0)
+ crypt-isaac (0.9.1)
+ diff-lcs (1.2.5)
+ ffi (1.9.3)
+ guard (1.4.0)
+ listen (>= 0.4.2)
+ thor (>= 0.14.6)
+ guard-rspec (2.0.0)
+ guard (>= 1.1)
+ rspec (~> 2.11)
+ i18n (0.6.11)
+ listen (0.7.3)
+ mime-types (2.3)
+ mini_portile (0.6.0)
+ multi_json (1.10.1)
+ net-ldap (0.1.1)
+ nokogiri (1.6.3.1)
+ mini_portile (= 0.6.0)
+ pg (0.17.1)
+ public_suffix (1.4.3)
+ r18n-core (1.1.11)
+ rack (1.6.11)
+ rack-protection (1.5.5)
+ rack
+ rack-test (0.6.3)
+ rack (>= 1.0)
+ rake (0.8.7)
+ rb-inotify (0.8.8)
+ ffi (>= 0.5.0)
+ rspec (2.99.0)
+ rspec-core (~> 2.99.0)
+ rspec-expectations (~> 2.99.0)
+ rspec-mocks (~> 2.99.0)
+ rspec-core (2.99.2)
+ rspec-expectations (2.99.2)
+ diff-lcs (>= 1.1.3, < 2.0)
+ rspec-mocks (2.99.2)
+ rubyzip (1.1.6)
+ safe_yaml (1.0.3)
+ selenium-webdriver (2.43.0)
+ childprocess (~> 0.5)
+ multi_json (~> 1.0)
+ rubyzip (~> 1.0)
+ websocket (~> 1.0)
+ sinatra (1.4.8)
+ rack (~> 1.5)
+ rack-protection (~> 1.4)
+ tilt (>= 1.3, < 3)
+ sinatra-r18n (1.1.11)
+ r18n-core (= 1.1.11)
+ sinatra (>= 1.3)
+ sqlite3 (1.3.9)
+ thor (0.19.1)
+ tilt (2.0.9)
+ tzinfo (0.3.55)
+ webmock (1.18.0)
+ addressable (>= 2.3.6)
+ crack (>= 0.3.2)
+ websocket (1.2.1)
+ xpath (0.1.4)
+ nokogiri (~> 1.3)
+
+PLATFORMS
+ ruby
+
+DEPENDENCIES
+ activeresource (>= 2.3.12, < 4.0)
+ appraisal (~> 0.4.1)
+ capybara (= 1.1.2)
+ guard (~> 1.4.0)
+ guard-rspec (= 2.0.0)
+ net-ldap (~> 0.1.1)
+ nokogiri (= 1.6.3.1)
+ pg
+ public_suffix (= 1.4.3)
+ rack-test (= 0.6.3)
+ rake (= 0.8.7)
+ rb-inotify (~> 0.8.8)
+ rspec
+ rspec-core
+ rubycas-server!
+ sqlite3 (~> 1.3.1)
+ webmock (~> 1.8)

README.md

@@ -1,5 +1,23 @@
 # RubyCAS-Server
 
+## Beyond Z Customizations
+
+The file lib/casserver/views/layout.erb has the login layout html. This is based on the main site, but it is modified, so must be maintained separately.
+
+The public/ folder has image and css assets brought off the main site. These are simply downloaded from the production site and renamed - to do this, load the join.bebraven.org site in your browser, view source and find the link rel=styleshet near the top. Download that file and save it in here as public/beyondz.css. They do NOT need to be maintained separately at this time. Currently required are the logo, favicon, and stylesheet.
+
+The file lib/beyondz.rb holds our authenticator. It uses a cooperative check_credentials http api on the public site to check against the main database. It is configured via config.yml for server (string), port (integer), ssl (boolean), and allow_self_signed (boolean) to know where to connect. The default ssl options is production-ready - it will verify certificates and use SSL. For development purposes, you may turn these options off with ssl: false.
+
+## End user flow
+
+The end user should always go to the service they want to use (portal.bebraven.org for example). The service then redirects them to the single sign on server, with a service parameter telling it to redirect them back once login is complete.
+
+user goes to canvas -> canvas sends them to sso -> sso sends back to canvas
+
+On the backend, the SSO server talks to the public site server and the service (canvas) server talks to the SSO server to validate login tickets. This should be SSL secured in production so the sso and canvas servers both need working client certificates, and the sso and public site servers need to be running https.
+
+The user master record is stored on the public site. User records also need to exist on the service - so a bz.org and canvas user need to exist with the same email address for the login to succeed end to end.
+
 ## Copyright
 
 Portions contributed by Matt Zukowski are copyright (c) 2011 Urbacon Ltd.
@@ -36,3 +54,51 @@ If you have questions, try the [RubyCAS Google Group](https://groups.google.com/
 
 RubyCAS-Server is licensed for use under the terms of the MIT License.
 See the LICENSE file bundled with the official RubyCAS-Server distribution for details.
+
+## Running in a local development environment using Docker
+
+Edit `/etc/hosts` and add these values.
+```Shell
+127.0.0.1 joinweb
+127.0.0.1 ssoweb
+127.0.0.1 canvasweb
+```
+Bring up the Join server locally b/c this Docker container is configured
+to point at it for the user database / credentials. Do this by following
+the instructions [here](https:/beyond-z/beyondz-platform#docker-setup)
+
+Then, from your application root just run:
+```Shell
+docker-compose up -d
+```
+When complete, the app will be available at: `http://ssoweb:3002`
+
+Note: the build will have a couple errors you can ignore. They don't
+seem to impact the functioning of the app. Just ignore:
+```Shell
+fatal: Not a git repository (or any of the parent directories): .git
+app/bin/rubycas-server maybe `gem pristine rubycas-server` will fix it?
+```
+
+Some things to keep in mind with Docker:
+* If there are build errors, run `docker-compose logs` to see what they
+ are.
+* The environment variables come from `docker-compose.yml` They are
+ injected into the container using `envsubst` in the
+`./docker-compose/scripts/docker_compose_run.sh` script.
+* If you change environment variables, rebuild to have them picked up by
+ running `./docker-compose/scripts/rebuild.sh
+* There are more scripts in `./docker-compose/scripts` to help you work
+ with the container(s).
+* If you change a file on the host (aka outside the container) it
+does not take effect inside the container. This application is rarely
+changed, so we don't mount a volume to allow files to be seamlessly
+changed inside and outside. To have a change take effect run
+`docker-compose/scripts/rebuild.sh`
+* Lastly, and this is IMPORTANT, the version of Ruby that we run on
+ production is 1.9.3. However, getting Docker building with that
+version has proven troublesome, so the Docker dev env runs Ruby 2.1. For
+that reason, DO NOT check-in the `Gemfile.lock` built on your local dev
+env or the update the `rubycas-server.gemspec`. If we have to rebuild
+gems on prod, we'll have to bite the bullet and upgrade the server (or
+consolidate the SSO server into the Join server

config/config.example.yml

@@ -18,6 +18,26 @@
 # The following are example configurations for each of these three methods:
 #
 
+# This is the domain of the main public website
+# It is used by the view to generate links back to the rest of the site on the login form.
+public_site_domain: join.bebraven.org
+
+# This is used to clear the login_message cookie after it is set by
+# a flash call on the Rails end. So it says like flash message saying
+# "your password is now reset". We read that cookie, display the message,
+# then clear the cookie so it isn't displayed twice. To clear the cookie,
+# we need to know the matching settings. cookie_domain is the configurable one.
+cookie_domain: .join.bebraven.org # this should be the *top* domain - so even for staging, it should be .join.bebraven.org still
+
+# If someone goes directly to the login url, this is where they end up
+# after a successful authentication. (They should never go directly there,
+# but copy/pasting the link could drop necessary form fields and get them
+# lost)
+default_service: http://yoursite.com/login/cas
+
+# This is the account number for google analytics. If this option is not
+# here, analytics script will not be added.
+google_analytics_account: UA-48011005-1
 
 ###
 ### WEBrick example
@@ -176,6 +196,21 @@ database:
 # user_table: users
 # username_column: username
 # password_column: password
+#
+
+# Beyond Z Authenticator
+authenticator:
+ class: BeyondZ::CustomAuthenticator
+ source: beyondz.rb
+ server: join.bebraven.org
+ # We can override ssl, port, and self signed options for dev
+ # The default is to use SSL.
+ # ssl: false
+ # port: 80
+ # allow_self_signed: true
+
+
+
 #
 # When replying to a CAS client's validation request, the server will normally
 # provide the client with the authenticated user's username. However it is

docker-compose.yml

@@ -0,0 +1,43 @@
+version: "3.5"
+services:
+
+ ssoweb:
+ build:
+ context: .
+ command: /app/docker-compose/scripts/docker_compose_run.sh
+ # Temporarily replace the command above with this if you want the container to just stay open 
+ # so you can connect and troubleshoot b/c the container exits when you bring it up.
+ #tty: true
+ ports:
+ - "3002:3002"
+ # Make changes done outside the container reflect inside the container without needing a rebuild by mounting a volume.
+ volumes:
+ - .:/app
+ networks:
+ - bravendev
+ depends_on:
+ - ssodb
+ environment:
+ RACK_ENV: development
+ DATABASE_NAME: casserver
+ DATABASE_USER: postgres
+ DATABASE_PASSWORD:
+ DATABASE_HOST: ssodb
+
+ ssodb:
+ image: postgres:9.3
+ volumes:
+ - sso-db:/var/lib/postgresql/data
+ networks:
+ - bravendev
+ environment:
+ POSTGRES_DB: casserver
+
+# Note all Braven web app docker dev envs use this same network so they can talk to each other.
+# E.g. the hostname joinweb will resolve inside the ssoweb container if they are on the same docker network.
+networks:
+ bravendev:
+ name: braven_dev_network
+
+volumes:
+ sso-db: