8.8.4.0 | Filters | Rackspace Auth User Filter

The Rackspace Auth User filter is for usage in Repose instances that sit in front of Keystone v1 and v2 deployments. It’s meant to be used for login requests to capture username for both rate limiting and user access events.

General Filter Information

Name: rackspace-auth-user
Released: v3.1.1 & v6.1.1.0+
Bundle: repose-filter-bundle
Default Configuration: rackspace-auth-user.cfg.xml
Configuration Schema: rackspace-auth-user-configuration.xsd

Prerequisites & Postconditions

Required Request Headers

Table 1. Request
Request Headers	Value	Conditions of Requirement
`X-SessionId`	Multi-Factor Authentication Session Id	Required during the second call of a multi-factor authentication attempt

Table 2. Response
Response Headers	Value	Conditions of Requirement
`WWW-Authenticate`	Multi-Factor Authentication Session Id	Required during the first call of a multi-factor authentication attempt

Required Preceding Filters

This filter has no dependencies on other filters.

Request Headers Created

Table 3. Request
Request Headers	Value	Conditions of Creation
`X-PP-User`	Username of the requester	Username present in the request body or the session id present for MFA. Prepended with `Racker:` if domain was present and had a value of `Rackspace`.
`X-User-Name`	Username of the requester	Username present in the request body or the session id present for MFA. Prepended with `Racker:` if domain was present and had a value of `Rackspace`.
`X-PP-Groups`	Configured value	Username present in the request body or the session id present for MFA.
`X-Domain`	Domain in the request	Username and Domain present in the request body or the session id present for MFA.

Request Body Changes

This filter does not modify the request body.

Recommended Follow-On (Succeeding) Filters

This filter needs to appear in the filter chain before any of the filters that need the information that derives and provides. That means the rate limiting filter when rate limiting, and herp filter when doing user access events. When doing both the order should be:

Rackspace Auth User
Highly Efficient Record Processor
Rate Limiting

For further details about the reasoning behind this ordering see user access events.

Response Body Changes

This filter does not modify the response body.

Response Headers Created

This filter does not create/modify any response headers.

Response Status Codes

This filter does not modify the response code.

Examples

rackspace-auth-user.cfg.xml

<?xml version="1.0" encoding="UTF-8"?>
<rackspace-auth-user
    xmlns='http://docs.openrepose.org/repose/rackspace-auth-user/v1.0'>

    <v1_1 content-body-read-limit="2048">  (1) (2)
        <group>1_1 Group</group> (3)
        <quality>0.75</quality> (4)
    </v1_1>

    <v2_0> (5)
        <group>2_0 Group</group> (3)
        <quality>0.80</quality> (4)
    </v2_0>

</rackspace-auth-user>

1	The `v1_1` element lets the filter know that you’d like to try to process request bodies using the 1.1 contract for auth requests. It is optional.
2	The `content-body-read-limit` attribute specifies how much of the body you’d like the filter to read before giving up and assuming it’s not present. Default: `4096`
3	The `group` element specifies what group name to use in the `X-PP-Groups` header. Default: `Pre_Auth`
4	The `quality` element specifies what quality to apply to the `X-PP-User` and `X-PP-Groups` headers, it should be a value between `0` and `1.0`. Default: `0.6`
5	The `v2_0` element is similar to the `v1_1` element but specifies that the filter should try to process request bodies using the 2.0 contract for auth requests and forgotten password requests. It is optional. The elements are not exclusive, and you can specify one, both, or neither. This element can also take a `content-body-read-limit` attribute with the same behavior as the `v1_1` element.