search

gwu-libraries / gw-sufia

GWU Libraries Self-Deposit Prototype - based on Sufia 4
2 stars 1 forks source link

Implement Shibboleth Authentication. #85

Closed kilahimm closed 10 years ago

kilahimm commented 10 years ago

Setup Devise for Shibboleth authentication. Some work has been done on this for Curate.\

Look at omniauth-shibboleth or devise-shibboleth-authenticatable

kilahimm commented 10 years ago

Installed devise-shibboleth-authenticatable and configured the server as a service provider (SP) with testshib.org identity provider (IdP). I can returned a valid Shibbloleth session through https://gwdev-sufia2.wrlc.org/Shibboleth.sso/Login however, I'm not sure how to over-ride the build in authentication for sufia.

kilahimm commented 10 years ago

I have this working using omniauth-shibbloeth against testshib.org on gwdev-sufia2 now. I will be adding shibboleth to gwsufia-test and documenting the process for further testing and validating the branch i started

kilahimm commented 10 years ago

Shibboleth auth is working with GW idP. There is a branch for testing. Currently need to add a database migrate to populate the users table with a few additional columns for Shibboleth.

Additionally need to explore how to override the default "login form". Would like to launch directly to the idP portal similar to Scholarsphere.

kerchner commented 10 years ago

@kilahimm code on the shibboleth branch looks good so far. Let me know if I can assist with overriding the login form, if it's not clear from how scholarsphere does it.

kilahimm commented 10 years ago

@kerchner if you're able to take a look at overriding the login form I'd appreciate another set of eyes. I haven't been able to figure out how they are doing it in ScholarsSphere.

kerchner commented 10 years ago

@kilahimm With pleasure. I'll let you know what I'm able to figure out.

kilahimm commented 10 years ago

added db migration to the shibboleth branch, need to add that step the readme. Shibboleth with prod-iDP is connected to gwsufia-test.wrlc.org now.

kilahimm commented 10 years ago

@mjgiarlo if you have a chance to look at this as well. We're trying to figure out how to skip over the devise login screen like in Scholarsphere. ie: when you click the "login" button you get taken directly to the SSO server. We have shibboleth working using omniauth-devsie. Currently shibboleth logins are initiated using a "Sign in with Shibboleth" link beneath the standard Username and Password prompts on the login screen. See https://gwsufia-test.wrlc.org/ for current status. (may need to be on VPN to access it)

kerchner commented 10 years ago

@mjgiarlo i second that emotion, and would actually love to get a walkthrough of how the login process works - both at the generic sufia level as well as the way you're doing it with scholarsphere. Looks like sufia is using devise, but it's taking me a while to figure out exactly which gem the /users/sign_in view is originating from. Still coming up to speed on rails as you can see :/

mjgiarlo commented 10 years ago

OK. I can point you at all the relevant stuff in ScholarSphere, though it's been a while since I've looked at it...

The routes -- https://github.com/psu-stewardship/scholarsphere/blob/develop/config/routes.rb#L8-L10 -- make sure that /logout and /login go to our own sessions controller.

The sessions controller -- https://github.com/psu-stewardship/scholarsphere/blob/develop/app/controllers/sessions_controller.rb#L15-L27 -- unsets relevant cookies and redirects to URLs as configured here: https://github.com/psu-stewardship/scholarsphere/blob/develop/config/environments/production.rb#L4-L5 (and allows for these URLs varying in dev and test envs)

In the application controller, which is a superclass of all other ScholarSphere controllers, we run a before_filter that performs an automatic logout if the HTTP headers don't have the right keys: https://github.com/psu-stewardship/scholarsphere/blob/develop/app/controllers/application_controller.rb#L43-54

We have a custom-defined Devise behavior to determine if a user is valid or not: https://github.com/psu-stewardship/scholarsphere/blob/develop/lib/devise/behaviors/http_header_authenticatable_behavior.rb

You can see this behavior included in our application controller here: https://github.com/psu-stewardship/scholarsphere/blob/develop/app/controllers/application_controller.rb#L10

When a user attempts to authenticate, ScholarSphere uses the http_header_authenticatable Devise strategy per this block in the User model: https://github.com/psu-stewardship/scholarsphere/blob/develop/app/models/user.rb#L17-L22

You can see the http_header_authenticatable model here -- https://github.com/psu-stewardship/scholarsphere/blob/develop/lib/devise/models/http_header_authenticatable.rb -- and the strategy here: https://github.com/psu-stewardship/scholarsphere/blob/develop/lib/devise/strategies/http_header_authenticatable.rb

If there is a failure in Devise authentication, we configure Devise to delegate those to the RedirectToWebAccessFailure class -- https://github.com/psu-stewardship/scholarsphere/blob/develop/config/initializers/devise.rb#L214-L216 -- which you can see here: https://github.com/psu-stewardship/scholarsphere/blob/develop/lib/redirect_to_web_access_failure.rb

kilahimm commented 10 years ago

@mjgiarlo this is exactly what I needed, I've been able to replicate the behavior from scholarssphere on our test instance.

kerchner commented 10 years ago

Resolved by #100