FreeIT

You're here:  Projects  >  CampusConnect  >  ECS proxy

ECS Proxy

On the one hand, the proxy handles the authentication of CampusConnect participants for the ECS, and on the other hand, it restricts and authorizes access to certain resources.

CampusConnect currently supports either "HTTP Basic Auth" or a certificate-based (X.509 Client/Server Certificates) authentication method. Regardless of which of the two methods is used, the proxy notifies the ECS of successful authentication by additionally transmitting an authentication ID assigned to the HTTP header variable "X-EcsAuthId" via a so-called "header injection".

Authorization for access to individual ECS resources is achieved, for example, through appropriate "Allow" or "Deny" directives in the proxy configuration.

The outsourcing of authentication and authorization to the proxy (e.g. the Apache web server, which can be operated as a (reverse) proxy) is a deliberate design decision that brings corresponding advantages:

• Maximum security
  Authentication modules in the proxy have years of development and operational practice behind them. Malfunctions are thus reduced to a minimum.

• Great flexibility
  The authentication and authorization modules available in the proxy are very diverse (e.g. Apache).

• High performance
  

  All unauthorized connection attempts are rejected in advance by the proxy and thus do not burden the ECS itself. If the proxy is designed appropriately, even denial of service attacks can be prevented.

  Efficient SSL/TLS connection handling (connection setup/termination).

There are many configuration examples ([1], [2]) for a reverse proxy configuration of the Apache web server, all of which can be used in principle as long as they pass the necessary authentication ID (X-EcsAuthId) to the ECS via "HTTP Header Injection". For an authentication via "Basic Auth" and the return of the user name as authentication ID it looks like this:

  RequestHeader unset X-EcsAuthId
  RewriteCond %{LA-U:REMOTE_USER} (.+)
  RewriteRule .* - [E=RU:%1]
  RequestHeader set X-EcsAuthId %{RU}e env=RU

In the case of authentication using X.509 certificates and the return of an authentication ID composed of the serial number and the email address of the client certificate:

  RequestHeader unset X-EcsAuthId
  RequestHeader set X-EcsAuthId %{SSL_CLIENT_M_SERIAL}e_%{SSL_CLIENT_S_DN_Email}e

<Location />
  AuthType Basic
  AuthName "CampusConnect-ECS"
  AuthBasicProvider file
  AuthUserFile /etc/apache2/ecs/pwds
  Require valid-user
</Location>

<Location /admin>
  AuthType Basic
  AuthName "ECS admin area"
  AuthBasicProvider file
  AuthUserFile /etc/apache2/ecs/pwds
  AuthMerging And
  Require user admin
</Location>

  apt-get install apache2
  a2enmod ssl headers rewrite proxy_balancer proxy_http lbmethod_byrequests
  a2dissite 000-default

After that we download the TAR archive ecs6_apache.tar and unpack it:

  tar --no-same-owner -xCf / ecs6_apache.tar

This archive contains the three files:

  etc/apache2/sites-available/000-ecs6.conf
  etc/apache2/ecs/auth.conf
  var/www/html/maintenance.html.off

The file "000-ecs6.conf" configures a virtual ECS host. In this file, of course, some statements must be adapted to the local conditions, such as ServerName, ServerAdmin, SSLCertificateFile, SSLCertificateKeyFile. But also the remaining statements should be looked at and understood (Apache Doku).

The file "auth.conf" regulates the resource access control. Remains the last file "maintenance.html.off". If you rename this file to "maintenance.html", the Apache proxy returns a maintenance page with the return code "503" (Service Unavailable), which is the usual return code for a service in maintenance.

Now that we have configured/installed an ECS virtual host, we still need to activate it:

  a2ensite 000-ecs6

In "000-ecs6.conf" a "Basic Auth" authentication is configured by default, so now we have to create a corresponding password file and at the same time enter the user "admin", where we are asked to enter a password for the new user "admin":

  htpasswd -mc /etc/apache2/ecs/pwds admin

All additional participants (Ilias, Moodle, StudIP installations) must also receive an account entry here, the ingredients of which must be transmitted to the administrators of the participants for their ECS configuration. Such a particpant account could be created as follows:

  htpasswd -m /etc/apache2/ecs/pwds Ilias_Uni_XYZ

When setting up a new participant at the ECS, the user name, i.e. "Ilias_Uni_XYZ" in our example, must also be entered as "Authentication-ID", because this user name is transferred to the ECS via "HTTP Header Injection" after successful authentication by the proxy using the "X-EcsAuthId" HTTP header variable mentioned above, which enables the ECS to uniquely assign the participant (authorization).

The proxy configuration is now complete and the ECS admin area can be accessed via the configured server name, e.g:

  https://deb-stretch-rails-server.example.com

In the login box that appears, we now need to enter the ingredients for the admin account we created earlier with the username "admin".

CampusConnect participants, e.g. Ilias learning systems, must of course first be registered at the ECS (Participants -> New Participant) so that they can belong to a CampusConnect network and interact and communicate with other CampusConnect participants within a community.