Navigation :

Basic

This login module expects Apache’s BasicAuth mechanism to perform the password checking.

Example configuration (not using client certificates) is:

<jarvis>
    <app>
        <login module="Jarvis::Login::BasicAuth">
            <parameter name="group_list" value="staff"/>
        </login>
        ...

Example configuration (using client certificates) is:

<jarvis>
    <app>
        <login>
            <parameter name="require_https" value="yes"/>
            <parameter name="remote_ip"     value="10.42.2.100"/>
            <parameter name="remote_user"   value="/C=NZ/ST=State/O=Company/CN=User Name Here"/>
            <parameter name="username"      value="admin"/>
            <parameter name="group_list"    value="admin,staff"/>
        </login>
        ...

The parameters are:

Attribute	Default	Notes
`require_https`	`no`	If `yes` then we require the connection to be HTTPS not HTTP.
`remote_ip`	(none)	If specified, this is a comma-separated list if IP addresses, one of which must be an exact match on the user’s IP address.
`remote_user`	(none)	This specifies the username exactly as it is specified in the Apache HTTP password file granting BasicAuth access to the user. If this is not specified then any BasicAuth user will be allowed access.
`username`	(none)	Jarvis username which the user will be granted. If not specified, the name passed from Apache BasicAuth will be used.
`group_list`	(none)	This is the comma-separated Jarvis group list to grant to this user. If not specified, then a single group with name identical to the assigned Jarvis username will be used.
`oauth_permissions`	(none)	A comma-separated list of OAuth2 permissions to give the user.

In the first example, we are using standard Basic Auth. Any client IP address is permitted. HTTPS is not required. Any configured basic auth username is allowed, and their Jarvis username will be the same as the username provided to Apache. All users will belong to a single group named staff.

In the second example we are using Apache FakeBasicAuth and Client certificates. HTTPS is required. Only access from the specified source IP address is permitted. Only the specified certificate Distinguished Name is permitted, exactly as given.

Note: That Apache’s FakeBasicAuth uses slashes instead of commas when deriving the DN. This matches what is configured for the client certificate in the Apache password file. The Jarvis username will appear as admin and the user will belong to two groups: admin and staff.

Use of CGI sessions with the basic authentication module will work as expected. A sessiondb configuration will maintain an active session using a session (stored as configured by the sessiondb configuration) and referenced via HTTP Cookie or URL SID parameter. A session will only be created if a request from the client does not include the session SID.

In some deployment scenarios the client may not provide back the SID in each request and so each request will trigger a new login request and a new session cookie. This can occur if the client is a software tool or library that drops cookie information.

To avoid new sessions being created and stored for each request when using Basic Authentication, a simple in-memory sessiondb session configuration can be used. This stops Jarvis generating session files stored on disk for every authenticated request for scenarios where the client does not provide the SID (via a Cookie or URL parameter) back:

<javis>
    <app>
        <sessiondb store="driver:inmemory;serializer:default;id:md5" cookie="requestid"></sessiondb>
    </app>
    ...

The cookie attribute is optional but naming the cookie requestid or similar reflects that the ID provided back in the cookie can be used to correlate requests with any logs on the server. This inmemory sessiondb driver avoids writing sessions to disk. Every request gets a new session.