Re: Shibboleth login

Hi Tonu:

In message
<CABDFm8hLpQOSDD1MTNnyctQ6JBgYYEH3Cx-2fSsmwBNBCeqmmQ@mail.gmail.com>,
Tonu Mikk writes:

>[...]
>I am now trying to set up Shibboleth login using the Apache and the
>ProxyPass method.
>
>I am not able to get the users automatically logged in using the HTTP Basic
>authentication as described in the config.ini .  First I get presented with
>the Shibboleth login and then I get presented with the Roundup interface
>that requires another login.
>
>I am quite sure I am able to set the REMOTE-USER value in the browser
>environment variable, but I am not sure if this value is passed to the
>Roundup's localhost web server instance. Any advice is appreciated!

After looking at roundup_server.py I wonder if REMOTE_USER is able to
be set via an http header. I don't see any mention of REMOTE_USER in
roundup_server.py.  Roundup_server.py has support for setting
HTTP_AUTHORIZATION from the http authorization header.

I also run a CGI setup which should be similar to a mod_python
configuration. In that configuration it uses os.environ to pass the
environment configured by the web server. This should allow the web
server to set REMOTE_USER.

(Note that the user can be validated from the HTTP authorization
header, but making an HTTP request with any valid user in the
REMOTE_USER header would allow the connection to authenticate as
that user. No validation is possible.)

>Here is the Apache virtual host configuration:
>
><VirtualHost *:80>
>        ServerName oranges.drc.umn.edu
>        Redirect / https://oranges.drc.umn.edu/
>
></VirtualHost>
><VirtualHost *:443>
>        ServerName oranges.drc.umn.edu
>#       DocumentRoot /var/www/html/oranges
>#       <Directory /var/www/html/oranges>
>#               Require all granted
>#               DirectoryIndex index.html
>#       </Directory>
>
>        <Location />
>                AuthType shibboleth
>                ShibRequestSetting requireSession 1
>                Require valid-user
>                RequestHeader set REMOTE-USER %{REMOTE_USER}s
>        </Location>

I don't remember how to interpret that, but doesn't that set the header
REMOTE-USER (not REMOTE_USER) to the name of the authenticated user?

>        ProxyPass /Shibboleth.sso !
>        ProxyPass / http://localhost:8080/oranges/

As I suggest above I don't think REMOTE_USER can be set from an http
header.

To see what the environment looks like, you can try adapting:

  https://rouilj.dynamic-dns.net/fossil/roundup_sysadmin/artifact?name=875cc7214087917b&txt=1

by saving it as home.about.html in your tracker's html directory. Then
add AboutPage() and any needed imports from

  https://rouilj.dynamic-dns.net/fossil/roundup_sysadmin/artifact?udc=1&ln=100,240&name=dfe168c0e02c32b7

to a file in your extentions directory and end the file with:

   instance.registerUtil('AboutPage', AboutPage)

The bit of code you are interested in is at lines 208-213 where I dump
the env array.

Then navigate to https://oranges/<tracker_name>/?@template=about to
view your modified home.about.html. You will probably need to log in
via shiboleth and then log in as admin (user id 1) using roundup's
form.

Are you running the roundup server bound to the loopback interface on
the same machine as apache? Also is it a restricted access machine? If
so, you can try adding:

  env['REMOTE_USER'] = self.headers.get('remote_user')

after the line:

  env['HTTP_AUTHORIZATION'] = self.headers.get('authorization')

in roundup_server.py.

Note that anybody that can make an HTTP request to the roundup server,
can become any user they want in roundup with this patch. I am not
quite sure what a secure method may be to allow this mechanism to
work.

Maybe enhancing the roundup_server to require a password that
authenticates the sending http server. So the sending server needs to
add a header:

  REMOTE_USER_AUTH: jfjoifeafdehfowqhfhfsfhldfhdfhR

and the value can be set in the roundup.ini file? Then change the code
so that REMOTE_USER is accepted from an http header only if this value
is present?

Anybody got other ideas on how to make this secure over an HTTP(s)
connection?

Even better does anybody want to try implementing it?

--
				-- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.