This is the I N  P R O G R E S S administrator documentation. For a general overview of vulture or the installation documentation click respectively on Vulture or Installation in the right menu.


Vulture is an HTTP reverse proxy. It does many security checks (authentication, rewriting, filtering) before proxying request from Internet to your web applications. With authentication enabled, vulture will open flows only to authenticated users. It also allows to your users to use only one password to access many different applications by learning and forwarding their different accounts.

Vulture includes :

  • Authentication (SSL, LDAP/AD, SQL, Radius)
  • Authentication forwarding (SSO)
  • HTTP headers modification on the fly
  • Flow encryption
  • Content filtering
  • URL Rewriting
  • Load balancing



Web servers


Content filtering and encryption


Administration logging in


When Vulture is installed (see Installation), go to https://localhost:9090. You may need to do a ssh forward or editing conf/httpd.conf in order to get apache listening on another IP if you don’t run your browser from the host running vulture. The default password for admin is admin.




Modifying the administrator password


After logging in, the page below will come up. The icon means that the user is an administrator. We will see thereafter why non administrator users can be usefull. Click on to change the password of “admin”.




Adding an interface


An interface is most likely an Apache process. By adding or editing an interface you will specify most of the apache options (ip and port, certificat, log format). Thereafter, we will bind applications on this interface and look at SSL and “SSO portal” features.

Back to the interface list you can see thoses icons :
: interface is up and running
: interface is down
: click on it to stop an interface
: click on it to commit changes and start or restart the interface

Leave the interface stopped as we dont have an application configured on it yet.



Adding an application


An application is mainly represented by its internet name. This is what users will type in the URL bar to join our application. Vulture will answer by providing content from the private URL. This is reverse proxying. We will see thereafter how vulture can require authentication before providing anything from the private URL. Add an application as shown below and start the interface.

Go back to the interface menu and start the interface. You should be able to type http://test or whatever you set the application name to and see your application. If you don’t, go to the FAQ menu.




Now that you have an application up and running let’s see how to restrict access to authorized users only. Vulture support LDAP, SQL, Radius and x509 client certificat authentication.
We first defines parameters of an authentication method by creating one and then associates this method to an application by editing the application’s authentication method parameter.
After associating an authentication method to an application you will be able to select an even more restricted pool of authenticated users using ACL. Thoses ACL are specific to an application.


If you use the same authentication method for two or more applications, user will be prompted for a password only one time.

SSO Forward

Don’t be confused between SSO and SSO Forward. The first one is a native thing in Vulture which means that you don’t need to do anything special to enjoy it as described above. The second one, which is called “SSO Forward” needs a little bit of configuration. “SSO Forward” is the ability of Vulture to learn users profile onto applications and propagate them on applications as far as the user is authenticated.


login = test
lang = fr

user = bill
password = gates

login = ads
passwd = coucou



Below is an example of informations needed by Vulture to do its query for authentication using SQL. Vulture support three encrytion algoritms for password comparaison besides plain text : SHA1, MD5 and Crypt.

Actually, you already have an SQL authentication method configured by default which is called “vultureng”. This is the own SQL user database of the administration interface. To enable it on an application just edit the “authentication method” of this application.

No need to restart the interface. It’s taken into account on the fly ;-).


Vulture in action


So, now, go on http://test or whatever you set the application name to and you will see this authentication form and should be able to connect using your admin account.


You can now add more users using the Users menu of the administration interface and experiment ACL by clicking on “ACL administration” in the application edition action menu.



Nothing particular here excepted for “Searching attribute is a DN”. This parameter is only needed if you plan to do ACLs regarding groups. Indeed, when looking for a member into groups, Vulture has to know either to use the whole DN of the user or just the CN. If you use an Active Directory and plan to configure ACLs by group check that.
For a common configuration of a Fedora Directory Server, user, group and “searching attibute in group” would be respectively uid, cn and uniquemember.
For a common configuration of an Active Directory server, user, group and “searching attibute in group” would be respectively samacountname, samaccountname and member.
Otherwise, for a common OpenLDAP configuration it would be something like shown below :


SSO Forward




  1. ^/secure => /index.php?do=secure [R]
  2. ^/redirect=(.*) => http://$1 [R]
  3. ^/admin => /administration [P]
  4. ^/admin => [403]
  5. .* => [NOCERT,R]
  6. ^/admin => /enroll.php [NOCERT,P]
  • 1. [R] means that the redirection will be sent to the user (external) from to
  • 2. Here is an example of perl regex : will be redirected to
  • 3. [P] means that the redirection will be transparent to the user and done internally by vulture itself. will be internally redirected to
  • 4. If there is “admin” in the URL, Vulture will return code 403 (forbidden).
  • 5. If the user doesn’t have a certificat it will be externally redirected.
  • 6. Same as in 5 but internally.


Headers rewriting




Connection to application 1

GET / HTTP/1.1

Host: app1:4242

HTTP/1.x 200 OK
Set-Cookie: vulture=5e18a8702397dd0fbf235fea96e6b123; path=/
Location: https://secure/?vulture=5e18a8702397dd0fbf235fea96e6b123

GET /?vulture=5e18a8702397dd0fbf235fea96e6b123 HTTP/1.1

Host: secure
HTTP/1.x 401 Authorization Required

GET /?vulture=5e18a8702397dd0fbf235fea96e6b123 HTTP/1.1
Host: secure
Authorization: Basic YWRtaW46YWRtaW4=

HTTP/1.x 200 OK
Set-Cookie: vulture=cccf9f0264cc644faf03ec9c6a79aced; path=/

Location: http://app1:4242

GET / HTTP/1.1
Host: app1:4242
Cookie: vulture=5e18a8702397dd0fbf235fea96e6b123

HTTP/1.x 200 OK

Then, connection to application 2

GET / HTTP/1.1
Host: app2:4242

HTTP/1.x 200 OK
Set-Cookie: vulture=32b61b6e70237dd0f97dd0feaf6b1b69; path=/
Location: https://secure/?vulture=32b61b6e70237dd0f97dd0feaf6b1b69

GET /?vulture=32b61b6e70237dd0f97dd0feaf6b1b69 HTTP/1.1
Host: secure
Cookie: vulture=cccf9f0264cc644faf03ec9c6a79aced

HTTP/1.x 200 OK
Location: http://app2/

GET / HTTP/1.1

Host: app2:4242
Cookie: vulture=32b61b6e70237dd0f97dd0feaf6b1b69

HTTP/1.x 200 OK