Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

issues with shibboleth login when served behind reverse proxy #3018

Open
nicolasfranck opened this issue Aug 26, 2021 · 4 comments
Open

issues with shibboleth login when served behind reverse proxy #3018

nicolasfranck opened this issue Aug 26, 2021 · 4 comments

Comments

@nicolasfranck
Copy link
Contributor

Please complete the following fields as applicable:

What version of the DMPRoadmap code are you running? (e.g. v2.2.0)

3.0.2

behaviour:

If you're using roadmap behind a reverse proxy,
and let mod_shib in apache pass all user attributes
via the http headers, you'll end up with a problem:
all values read as "ASCII-8BIT" (which is actually ISO-8859-1),
because that is the expected encoding in http headers,
and omniauth-shibboleth does not even try to take this
into account, although the shibboleth documentation clearly
states that it should.

Result: the code halts when it tries to store attrs into the Identifier:

Encoding::UndefinedConversionError ("\xC3" from ASCII-8BIT to UTF-8):

which happens here

I am not sure if this is problematic when storing the name and first_name
into the user record.

If you want to see how this happens try the following:

h = { name: "café" }
h[:name].force_encoding("ASCII-8BIT")
h.to_json

I know, roadmap is not the cause of this, but maybe you have encountered users that experienced this problem?
Any idea on how to solve this?

@briri
Copy link
Contributor

briri commented Sep 7, 2021

Hi @nicolasfranck,

Are you using puma or a different app server? We have the following apache config for our Shib SP which is forwarding the information over correctly:

    <Location /Shibboleth.sso>
      AuthType shibboleth
      require shibboleth
      SSLRequireSSL
    </Location>
    
    <Location /users/auth/shibboleth/callback>
      AuthType shibboleth
      require shibboleth
      ShibUseHeaders On
      SSLRequireSSL
    </Location>

@nicolasfranck
Copy link
Contributor Author

I use puma as backend server. The shibboleth parameters
are passed by HTTP header as shown in your configuration.

I "fixed" this by overriding this function call in omniauth-shibboleth:

https://github.com/DMPbelgium/roadmap/blob/master/config/initializers/devise_ugent.rb#L66

the gem seems to be abandoned? They do not react to other issues as well..

This is not a roadmap issue, but one might stumble upon this problem.
Have you tested this against names with non English characters in it (accents and others)?

@briri
Copy link
Contributor

briri commented Sep 7, 2021

Yes, we have shib generated user accounts with non-English characters (e.g. ç, ö, ñ, etc.)

It could be that the identity providers you are receiving the user info from package things up differently. We use the InCommon federation and EduGain which standardize the response.

@briri
Copy link
Contributor

briri commented Sep 7, 2021

The gem does appear to have been abandoned :/

This will be problematic going forward if Shibboleth changes in the future.

The gem's owner has only had 6 contributions (to public repos) in the past year so I'm thinking they will not continue support in the near future.

I'm reluctant to take on ownership of the repository (or a fork of it) since we have such limited bandwidth. What do you think @raycarrick-ed and @nicolasfranck?

The current repo has not been updated in 4 years and has several outstanding issues and a PR. I also reviewed the forks and they have no new commits.

Many of the DMPRoadmap installations rely on Shibboleth integration, so it may be worthwhile to commit to supporting a new fork of the gem. An alternate option would be to migrate away from Shibboleth integration and over to ORCID. This would require serious policy discussions for each installation and a willingness to disrupt the User login/account creation workflows.

@mariapraetzellis mariapraetzellis added this to Pending in Current sprint Sep 7, 2021
@mariapraetzellis mariapraetzellis removed this from Pending in Current sprint Dec 8, 2021
@dsisu dsisu added this to Pending in Current sprint Sep 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
No open projects
Development

No branches or pull requests

2 participants