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 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.
...
Within each CGI variable (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.
Server Variables
| Info |
|---|
title |
|---|
Always use Server VariablesCurrently, the SP supports the use of 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 server variables. The term 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.
...
Most of the variables created by the SP are controlled by you, and correspond to mapped attributes. A few are built into the SP and can't be renamed. Currently these are hardwired but in a future version most of them will be produced through the use of the recently introduced attribute extractor of type "Assertion". The built-in variables can be disabled (to avoid duplication with the extractor) with the content setting of exportStdVars="false".
Variable | Meaning |
|---|
Shib-Application-ID |
The applicationId property The applicationId property derived for the request. |
Shib-Session-ID | The internal session key assigned to the session associated with the request. |
Shib-Identity-Provider | The entityID of the IdP that authenticated the user associated with the request. |
Shib-Authentication-Instant | The ISO timestamp provided by the IdP indicating the time of authentication. |
Shib-Authentication-Method |
The AuthenticationMethod or <AuthnContextClassRef> value The AuthenticationMethod or <AuthnContextClassRef> value supplied by the IdP, if any. |
Shib-AuthnContext-Class |
The AuthenticationMethod or <AuthnContextClassRef> value The AuthenticationMethod or <AuthnContextClassRef> value supplied by the IdP, if any. |
Shib-AuthnContext-Decl |
The <AuthnContextDeclRef> value The <AuthnContextDeclRef> value supplied by the IdP, if any. |
Shib-Handler | The self-referential base location of the SP's "handlers" for use by applications in requesting login, logout, etc. |
| Expand |
|---|
| title | Tool-Specific Examples |
|---|
|
...
expand |
Java | JavaEnvironment Access| Code Block |
|---|
title | Java Environment Access |
|---|
request.getAttribute("Shib-Identity-Provider") | | Code Block |
|---|
title |
| Code Block |
|---|
request.getHeader("Shib-Identity-Provider") |
| Warning |
|---|
title |
|---|
Struts 2 IssueAn issue has been identified using environment variable access using Struts 2. When accessing a request attribute whose name contains a hyphen, and the attribute does not exist in the session, rather than returning a null value the Struts environment returns an instance of java.math.BigDecimal with the value '0'. This is related to Struts use of a wrapped servlet request and evaluation of the attribute name as an OGNL expression. Applications retrieving attribute data within this framework should take care to check the return value of request.getAttribute(name) for attribute names containing a hyphen. This affects all the custom SP variables noted above as well as certain default attribute names such as 'persistent-id'. |
Shibboleth attributes are by default UTF-8 encoded. However, depending on the servlet contaner configuration they are interpreted as ISO-8859-1 values. This causes problems with non-ASCII characters. The solution is to re-encode attributes, e.g. with: | Code Block |
|---|
| String value= request.getHeader("givenName");
value= new String( value.getBytes("ISO-8859-1"), "UTF-8"); |
|
| Expand |
|---|
| | Code Block |
|---|
title |
PHP Environment Access| Code Block |
|---|
$_SERVER["Shib-Identity-Provider"] | | Code Block |
|---|
title |
| Code Block |
|---|
$_SERVER["HTTP_SHIB_IDENTITY_PROVIDER"] |
|
| Expand |
|---|
Cold Fusion | Cold Fusion |
|---|
| Code Block |
|---|
|
Environment Access| Code Block |
|---|
CGI.Shib-Identity-Provider | | Code Block |
|---|
title | ColdFusion
| Code Block |
|---|
CGI.HTTP_SHIB_IDENTITY_PROVIDER |
Shibboleth attributes are by default UTF-8 encoded. However, in Coldfusion they are interpreted as ISO-8859-1 values. This causes problems with non-ASCII characters. The solution is to re-encode attributes, e.g. with: | Code Block |
|---|
<cfset surname = charsetEncode(toBinary(toBase64(CGI.givenName,"iso-8859-1")),"utf-8")> |
|
| Expand |
|---|
| | Code Block |
|---|
title |
ASP | Code Block |
|---|
Request("HTTP_SHIB_IDENTITY_PROVIDER") |
|
| Expand |
|---|
| | Code Block |
|---|
title |
ASP.NET | Code Block |
|---|
Request.Headers("Shib-Identity-Provider") |
|
| Expand |
|---|
|
| Code Block |
|---|
| title | Ruby on Rails Environment Access
| Code Block |
|---|
request.env["Shib-Identity-Provider"] |
| Code Block |
|---|
title |
| Code Block |
|---|
request.headers[:HTTP_SHIB_IDENTITY_PROVIDER] |
|---|
...