The primary mechanism by which the SP makes attribute and other session information available to applications is by "exporting" the data to a set of environment server variables or HTTP request headers that are generally exposed to web applications using the CGI (Common Gateway Interface) defined in the early days of the web.
Originally, web applications ran as scripts or executable programs invoked by web servers as a separate process. The CGI was a specification for a set of environment variables passed to the new process by the web server. In addition to a set of relatively fixed elements, every request header attached to the request was translated into a variable by normalizing it its name and prefixing it with "HTTP_".
While most applications today are not written as actual "CGI applications" and tend to be executed by interpreted scripting plugins deployed with the web server, the CGI and its conventions are supported in some form by all development tools.
Within each CGI variable or header (see below), multiple attribute values are separated by a semicolon, and semicolons in values are escaped with a backslash. The data should be interpreted as UTF-8, which is a superset of ASCII.
| Table of Contents |
|---|
...
Server Variables
| Info | ||
|---|---|---|
| ||
Currently, the SP supports the use of environment server variables on all versions of Apache and IIS versions greater than 7. You should always use this mechanism with web servers that support it. |
The safest mechanism, and the default for servers that allow for it, is the use of environment server variables. The term is somewhat generic because environment variables don't necessarily always imply the actual process environment in the traditional sense, since there's often no separate process. It really refers to a set of controlled data elements that the web server supplies to applications and that cannot be manipulated in any way from outside the web server. Specifically, the client has no say in them.
In many cases, access to environment server variables is even case sensitive; a mapped attribute with an id of "My-Attribute" might only be accessible as a variable with that exact name. Accessing "MY-Attribute" or "My_Attribute" often won't work. This is a good thing, since it's unambiguous.
Note however that Perl applications using the its typical CGI library will have environment variable names altered: hyphens ('-') are turned into underscore underscores ('_'). The above example will would be accessed as "My_Attribute".
Request Headers
Unfortunately, not all web servers currently expose a mechanism to create custom variables from within server extensions. This is a bug; all web servers should support this in some way, but Sun/iPlanet does not.
On these On some legacy platforms, the SP is forced to substitute the use of custom HTTP request headers. This is convenient, in that the CGI requires custom headers to be passed along to applications, but is also dangerous and difficult to secure. The SP has had at least two separate major security patches resulting from this mechanism. This is because the header mechanism is really about passing information from the client to the application; any browser can be manipulated to supply arbitrary headers quite easily with little skill.
...
"REMOTE_USER" is a special environment variable established by the CGI for use in passing the "authenticated username" to applications. It is NOT a header, and is designed to be set only when the web server is informed by a module that the user accessing the application is known. It is empty or unset otherwise. In many tools, it may be accessed outside of the usual APIs and may have a dedicated function for obtaining it (e.g., Java servlets have a getRemoteUser method).
Shibboleth is somewhat unique among SSO tools in that it does not necessarily allow for require that "REMOTE_USER" to be set, even if a user has logged in. This is for two reasons: privacy and extensibility.
...
The other reason why "REMOTE_USER" is handled differently by the SP is the generic notion of identity that underlies federation. There is no single way of identifying users once you're working on a global scale. Different technologies all have their own approaches, and no single attribute or syntax can be assumed. SAML itself leaves this issue completely open, although there are certainly best practices. As a result, the SP handles "REMOTE_USER" by leaving it up to the configuration as to which of a set of several designated attributes can be are used to populate it.
Custom SP Variables
...