Non-CAS authentication

[caseywatts]

2014-09-28

For now, we're going to implement Devise authentication with the devise_cas_authenticatable gem for CAS. We will also try to write up example migrations and instructions for alternative Devise authentication schemes.

To Do:

• Add devise gemlater
• Add devise_cas_authenticatable gem
• Set up devise authentication before_filters instead of old RubyCAS filters
• Write migration to change login column name to username (delete current migration)
• Replace all uses of login for ActiveRecord lookups with username
• Remove custom current_user method in lieu of built-in Devise method

2014-10-12

Most / all of the above was completed today and almost all of the current test suite is passing. My thoughts are outlined in the comment below; I'll try to turn them into a proper to-do list soon.

2014-10-13

All tests now pass. I tried getting database_authenticatable working and it was messy, but I think providing example code at least for that case is important. If I'm strugging to get this working, so will future clients. I'd like to see if we can do the following:

• remove all CAS workflow dependencies make sure both authentication methods work
  • redirect hackery
  • user new hackery
  • any other hackery :-P
• get database_authenticatable working, using our current user resource
  • add required parameters to strong params (commented out by default)
  • make sure edit and update work
  • set up proper Devise configuration in devise.rb, with options for both username or email login
  • set up required database migrations (with .example file extension so they don't run by default)
  • COMMENT ALL THE THINGS
• write tests for authentication (I'm not sure where these go... maybe just in the controller specs, one context per controller?)
• think about implementing other devise modules
  • recoverable
  • trackable
• clean up devise.rb with only required / related options and comment where necessary
• document the procedure for enabling database_authenticatable either in the README or wiki or both
• look into making database_authenticatable the default and switching to CAS using the deploy script / variable (related to Document and set up generalized deployment #683)

2014-10-19

• look into implementing email LDAP lookup for database authenticatable

2014-10-25

• manually test :recoverable
  • look at generated devise views to figure out how to set up the UI elements
• write integration tests for sign up (using password authentication)
• write integration tests for resetting password (obviously using password authentication)
• go through devise.rb again and take out settings that shouldn't be changed :-)
• document the process for enabling CAS authentication in the README
• document our authentication workflow in the wiki
• look into using LDAP lookup via e-mail for password authentication

[caseywatts]

I'm a big fan of using external authentication like omniauth for a google account, etc
Let's try one of those? :)

[iansuvak]

I've implemented omniauth version of cas.. Adam and I decided that it would be too much to enable both simultaneously so we will make it a setting only settable at install time. Stalling until @maltyeva is done with the app settings refactoring

[iansuvak]

I am done for the summer but here is the summary fo the current status of the Devise branch and possible problems...

The CAS server host adress is setup in devise initializer as CAS_HOST variable. That is the only bit of code setup necessary for this.

I have implemented an extra step in the application setup where the Authorization settings and the LDAP settings are configured. The Devise works as following: It uses authenticate_user! before filter to check if the user is authenticated. It is skipped on public pages. If a user is not authenticated it redirects to sessions#new action which redirects to the CAS authentication or to the sign-in page which is a sessions#new view.

Past the sign in page CAS authentication system does not interact at all with devise controllers. They are assigned a random 20 character password and their e-mail confirmation is skipped.

The Devise users on the other hand use new, create, and update actions of the devise controller that I have overridden in order to update e-mails and logins properly. All Devise controllers are located inside the gem but the ones that I am overriding are contained in the /controllers/users/ folder. Their views are in the subfolders of the view/users folders, and the rest of the views, controllers for which aren't overridden are in the views/devise folder.

The admin user is auto-confirmed but this can be changed in the application_setup controller, all other users that are created are sent a confirmation e-mail, and have to confirm before they can sign in. They can be given a grace period by uncommenting a line in the devise initializer and setting a time period.

If Admin edits users profiles regular users CRUD actions are called rather than the registrations controller ones.

I don't see any immediate problems other than if the LDAP server settings are not correctly entered search_ldap function will fail and die a horrible death, and bring down the rest of everything so that should probably be handled.

In general devise modules are added and removed in the users.rb model and the routes are managed with the devise_for method in the routes.rb. there I have skipped registrations module and manually defined routes for certain calls to prevent devise from overriding old users CRUD actions.

Also Devise provides its own current_user method so I deleted our old one and the helpers.

App_setup works great if you don't do silly things to it but I wouldn't consider it bomb-proof.

Although I won't have my computer with me in Peru I will have my phone and hopefully some form of WiFi so I will be able to answer questions via e-mail if you have any.

[orenyk]

It looks like a lot of work was done with this a while ago; not sure how much of it is still usable. I'm wondering if it might be possible to have CAS as an authentication option along with others, that would probably be best so that it's usable outside of Yale, but there are a lot of other Yale-specific aspects of the app we might want to generalize out. That's discussion for a different issue, leaving this open for further discussion.