Bio::Das::ProServer::Authenticator::ip - authenticates DAS requests by IP address

$LastChangedRevision: 453 $

To authenticate a request:

  my $auth = Bio::Das::ProServer::Authenticator::ip->new({
    'config' => {
                 'authallow' => $, # IP whitelist
                },
  });

  my $allow = $auth->authenticate({
    'peer_addr' => $, # packed
    'request'   => $, # HTTP::Request object
    ...
  });

Once authenticated the IP address is stored:

  if ($allow) {
    my $ip    = $auth->ip();
  }

To simply perform IP address authentication but not deny requests, configure the source with a lax IP range (e.g. "0/0"). This allows the source to alter its behaviour in a more subtle fashion (e.g provide different data for different sites).

Authenticates requests according to a 'whitelist' of IP address ranges. Requests from clients not within one of these ranges are denied.

The IP addresses that are checked against the whitelist are: 1) that of the socket connection 2) those listed in the X-Forwarded-For HTTP header

The latter is necessary for clients and servers operating behind proxies.

IMPORTANT NOTE: Because IP addresses can be spoofed by clients, this is NOT a robust method of securing data.

The whitelist for IP addresses is configured in the source INI section, using any combination of specific, additive, range or CIDR format IPs. Valid separators are comma and semicolon.

  [mysource]
  authenticator = ip
  authallow     = 1.2.3.4,193.62.196.0 + 255 , 123.123.123.1 - 123.123.123.10 ; 192.168/16

  Requires: a hash reference containing details of the DAS request
  Returns:  either nothing (allow) or a HTTP::Response (deny)

  my $allow = $oAuth->authenticate({
    'peer_addr' => $, # packed (socket IP address)
    'request'   => $, # HTTP::Request object (for X-Forwarded-For header)
    ...
  });

  my $sIp = $oAuth->ip();

  my $auth = Bio::Das::ProServer::Authenticator::ip->new({
    ...
    'debug'  => 1,
  });

Carp

Net::IP

Socket

Bio::Das::ProServer::Authenticator

Clients that are separated from the server by an anonymising HTTP proxy (i.e. one that does not reveal the client's IP address in the X-Forwarded-For HTTP header) will always fail this method of authentication.

Note that clients may spoof an IP address in the X-Forwarded-For header. Therefore this method of authentication is not a robust security precaution.

None reported.

Andy Jenkinson <andy.jenkinson@ebi.ac.uk>

Copyright (c) 2008 EMBL-EBI