nginx http shibboleth下载nginx http shibboleth源代码下载

nginx http shibboleth

网站数据

v2.0.2

下载

Nginx的Shibboleth auth请求模块

该模块允许Nginx通过Shibboleth的FastCGI授权者与Shibboleth合作。该模块需要特定的配置才能正确工作，以及系统上可用的Shibboleth的FastCGI授权器应用程序。它的目的是类似于Apache的MOD_SHIB的一部分，尽管Shibboleth授权和身份验证设置是通过Shibboleth2.xml而不是在Web服务器配置中配置的。

使用此模块针对location块配置，根据Shibboleth的FastCGI授权者的子要求的结果，在NGINX中授权传入请求。在此过程中，该模块可用于将成功的授权者响应从NGINX的原始请求复制为标题或环境参数，以供任何后端应用程序使用。如果授权不成功，则授权者响应状态和标题将返回客户端，拒绝访问或重定向用户的浏览器（例如，如果是这样的，则是Wayf页面）。

该模块在访问阶段起作用，因此可以通过satisfy指令将其与其他访问模块（例如access ， auth_basic ）结合使用。该模块也可以与ngx_http_auth_request_module一起编译，尽管在同一location块中使用这两个模块的使用未经测试且不建议。

阅读有关下面行为的更多信息，并咨询配置，以获取有关避免使用标头属性的重要说明。

有关为什么这是一个专用模块的更多信息，请参见https://forum.nginx.org/read.php?2,2,238523,238523#mmsg-238523

指令

以下指令添加到您的NGINX配置文件中。下面提到的上下文显示了它们可以添加的位置。

shib_request <uri> |关闭

上下文： http ， server ， location

默认值： off

切换Shibboleth auth请求模块并设置URI，该模块将被要求授权。配置的URI应参考指向您的Shibboleth FastCGI授权器的NGINX位置块。

根据FASTCGI授权者规范，将返回由子要求引起的HTTP状态和响应的标题。一个（潜在意义的）警告是，由于NGINX目前对子要求的运作方式（授权者有效地要求），请求主体不会转发给授权者，同样，授权机的响应机构也不会将其退还给客户。

但是，配置的URI不限于使用FastCGI后端来生成响应。这在测试期间或其他方式可能很有用，因为您可以使用Nginx内置的return并rewrite指令来产生合适的响应。此外，尽管操作可能受到上述警告的影响，但该模块可与任何FASTCGI授权者一起使用。

警告

shib_request指令不再需要shib_authorizer标志。必须将其删除才能开始。无需其他更改。

shib_request_set <变量> <value>

上下文： http ， server ， location

默认值： none

验证请求完成后，将variable设置为指定value 。该value可能包含验证请求响应中的变量。例如， $upstream_http_* ， $upstream_status以及nginx_http_upstream_module文档中提到的任何其他变量。

该指令可用于将Shibboleth属性引入后端应用程序的环境，例如用于FastCGI PHP应用程序的$ _SERVER，这是建议这样做的方法。有关示例，请参见配置文档。

shib_request_use_headers打开|关闭

上下文： http ， server ， location

默认值： off

笔记

在v2.0.0中添加。

将shibboleth授权者响应中的属性复制到主要请求中，作为标题，使其可用于上游服务器和应用程序。仅当您的上游/应用程序不通过shib_request_set支持服务器参数时，才使用此选项。

启用此设置后，提取以Variable-*开头的授权器响应标头，将Variable- - 子字符串从标题名称中剥离，然后在将其发送到后端之前将其复制到主请求之前。例如，授权者响应标题，例如Variable-Commonname: John Smith将导致Commonname: John Smith被添加到主要请求中，从而发送到了后端。

提防欺骗- 您必须确保保护后端应用程序免受标头注入的保护。请咨询如何实现这一目标的配置示例。

安装

该模块可以在静态或动态上进行编译，因为在NGINX 1.9.11中引入了动态模块。动态模块的实用结果是可以加载它们，而不是永久存在和启用的静态模块。

获得该模块包装版本的最简单方法是使用Nginx的PKG-Oss工具，该工具提供了动态模块的包装，以与主要存储库中的Nginx官方发行版一起安装，并有助于避免需要手动编译Nginx。

否则，要动态使用此模块编译Nginx，请在构建Nginx时将以下选项传递给./configure ：

 -  add-dynamic-module = <路径>

您需要通过nginx.conf ：

 load_module/path/to/modules/ngx_http_shibboleth_module.so;

并重新加载或重新启动NGINX。

要使用此模块静态编译Nginx，请在构建Nginx时将以下选项传递给./configure ：

 -add-module = <路径>

使用静态构建，由于模块是内置的NGINX，因此无需额外加载。

配置

有关配置nginx/shibboleth环境的完整详细信息，请参见https://github.com/nginx-shib/nginx-http-shibboleth/blob/blob/master/master/config.rst上的文档。

示例server块由以下内容组成：

 #FastCGI authorizer for Auth Request module
location = /shibauthorizer {
    internal ;
    include fastcgi_params;
    fastcgi_pass unix:/opt/shibboleth/shibauthorizer.sock;
}

#FastCGI responder
location /Shibboleth.sso {
    include fastcgi_params;
    fastcgi_pass unix:/opt/shibboleth/shibresponder.sock;
}

# Using the ``shib_request_set`` directive, we can introduce attributes as
# environment variables for the backend application. In this example, we
# set ``fastcgi_param`` but this could be any type of Nginx backend that
# supports parameters (by using the appropriate *_param option)
#
# The ``shib_fastcgi_params`` is an optional set of default parameters,
# available in the ``includes/`` directory in this repository.
#
# Choose this type of configuration unless your backend application
# doesn't support server parameters or specifically requires headers.
location /secure-environment-vars {
    shib_request /shibauthorizer;
    include shib_fastcgi_params;
    shib_request_set $shib_commonname $upstream_http_variable_commonname ;
    shib_request_set $shib_email $upstream_http_variable_email ;
    fastcgi_param COMMONNAME $shib_commonname ;
    fastcgi_param EMAIL $shib_email ;
    fastcgi_pass unix:/path/to/backend.socket;
}

# A secured location. All incoming requests query the Shibboleth FastCGI authorizer.
# Watch out for performance issues and spoofing!
#
# Choose this type of configuration for ``proxy_pass`` applications
# or backends that don't support server parameters.
location /secure {
    shib_request /shibauthorizer;
    shib_request_use_headers on;

    # Attributes from Shibboleth are introduced as headers by the FastCGI
    # authorizer so we must prevent spoofing. The
    # ``shib_clear_headers`` is a set of default header directives,
    # available in the `includes/` directory in this repository.
    include shib_clear_headers;

    # Add *all* attributes that your application uses, including all
    #variations.
    more_clear_input_headers 'displayName' 'mail' 'persistent-id' ;

    # This backend application will receive Shibboleth variables as request
    # headers (from Shibboleth's FastCGI authorizer)
    proxy_pass http://localhost:8080;
}

请注意，我们使用标头摩尔 - nginx模块清除潜在的危险输入标头，并避免欺骗的潜力。只要后端仅从环境参数读取数据，就不容易带有环境变量的示例。

可以使用默认配置来清除Shibboleth授权者的基本标头，但是您必须确保为应用程序使用的所有属性编写自己的清晰指令。请记住，某些应用程序将尝试从环境中读取shibboleth属性，然后倒入标题，因此，即使您不使用shib_request_use_headers ，请查看您的应用程序代码。

通过使用shib_request_set ，可以使用一个默认的参数文件，您可以用作NGINX include该文件，以确保所有Core Shibboleth变量都从FastCGI授权器传递给了应用程序。包括许多默认属性，因此请删除应用程序不需要的属性，并添加所需的联邦或IDP属性。可以通过简单地将fastcgi_param指令更改为uwsgi_param ， scgi_param ，或者是FastCGI的上游，可以重复使用此默认参数文件。

陷入困境

诸如Shibboleth auth请求之类的子征用未通过标头过滤器处理。这意味着，如果将ADD_HEADER（例如add_header等内置指令配置为A /shibauthorizer块的一部分。如果您需要操纵子修复标题，请使用more_set_headers中的模块headers-more 。
请参阅https://forum.nginx.org/read.php?29,257271,257272#MSG-257272。

行为

该模块在可能的情况下遵循FASTCGI授权器规范，但有一些显着的偏差 - 有充分的理由。因此，行为是：

授权者子要求由原始请求的各个方面组成，除了请求主体，因为nginx不支持请求实体的缓冲。由于Shibboleth FastCGI授权者不考虑请求主体，因此这不是问题。
如果授权者子要求返回200状态，则允许访问。
如果启用了shib_request_use_headers ，则提取以Variable-*开头的响应标头，将Variable- - 子字符串从标题名称中剥离，然后复制到主请求中。其他授权者响应标头未在没有Variable-前缀，并且响应主体被忽略。 FastCGI规格要求将Variable-*名称值对包含在FastCGI环境中，但是我们将它们制成标题，使它们可以与任何后端一起使用（例如proxy_pass ），而不仅仅是将自己限制在FastCGI应用程序中。通过将Variable-*数据作为标头传递，我们最终会遵循ShibUseHeaders On in mod_shib for apache的行为，该行为将这些用户属性作为标头传递。
为了将属性作为环境变量（等效于mod_shib的ShibUseEnvironment On ），必须使用每个属性的shib_request_set指令手动提取属性。对于所有属性，这都无法（当前）完成，因为每个后端都可以以不同的方式接受参数（ fastcgi_param ， uwsgi_param等）。欢迎拉动请求自动化此行为。
如果授权者子重点返回任何其他状态（包括重定向或错误），则授权者响应的状态和标题将退还给客户端。
这意味着，在401 Unauthorized或403 Forbidden ，将拒绝访问权限，并且将从WWW-Authenticate者传递给客户端。所有其他授权者响应（例如3xx重定向）都将其传递给客户，包括状态和标题，允许诸如Wayf页面的重定向和Shibboleth reversonder（ Shibboleth.sso ）正确工作。
FastCGI授权器规格要求响应主体返回客户端，但是由于NGINX当前不支持缓冲subrequest响应（ NGX_HTTP_SUBREQUEST_IN_MEMORY ），因此有效地忽略了授权者响应主体。解决方法是让nginx提供自己的error_page ，例如：
```
 location /secure {
   shib_request /shibauthorizer;
   error_page 403 /shibboleth-forbidden.html;
   ...
}
```
如果Shibboleth授权者拒绝用户访问此位置，则为给定的错误页面。如果未指定error_page ，则NGINX将提供其通用错误页面。
请注意，这不适用于shibboleth响应者（通常在Shibboleth.sso中托管），因为它是FastCGI响应者，并且NGINX与此完全兼容，因为没有使用子内容。
有关更多详细信息，请参见https://forum.nginx.org/read.php?2,238444,238453。

尽管该模块专门针对Shibboleth的FastCGI授权者，但它可能会与其他授权者一起使用，并牢记与上面规格的偏差。

测试

每当对存储库进行新提交或打开新的拉请请求时，测试将在GitHub操作（使用此配置）上自动运行。如果某件事破裂，您将被告知，结果将在Github上报告。

使用简单的bash脚本的组合编写测试，以与Nginx的不同版本和配置和Test :: Nginx Perl Test脚手架进行集成测试的组合编辑。请咨询先前的链接，以获取有关如何扩展测试的信息，也请参考基础测试::基本文档，诸如blocks（）函数之类的方面。

集成测试是通过CI自动运行的，但也可以手动运行（需要安装Perl＆CPAN）：

 cd nginx-http-shibboleth
cpanm --notest --local-lib= $HOME /perl5 Test::Nginx
# nginx must be present in PATH and built with debugging symbols
PERL5LIB= $HOME /perl5/lib/perl5 prove

帮助和支持

Shibboleth配置和NGINX或Web服务器设置的支持请求应针对Shibboleth社区用户邮件列表。有关详细信息，请参见https://www.shibboleth.net/community/lists/。

调试

由于NGINX/FASTCGI/Shibboleth堆栈的复杂性质，调试配置问题可能很困难。这是一些要点：

确认nginx-http-shibboleth成功地构建和安装了Nginx。您可以通过运行nginx -V进行检查，并检查--add-module=[path]/nginx-http-shibboleth或--add-dynamic-module=[path]/nginx-http-shibboleth 。
如果使用nginx的动态模块，请确认您已使用load_module指令来加载此模块。如果您忘记加载模块，您对shib_request的使用和其他指令将失败。
如果使用与我们测试的版本不同或使用其他第三方模块不同的版本，则应在上面运行测试套件以确认兼容性。如果任何测试失败，请检查您的配置或考虑更新您的NGINX版本。
Shibboleth配置：检查您的shibboleth2.xml和关联的配置，以确保您的主机，路径和属性正确发布。示例配置可以帮助您识别键“抓”以配置shibboleth2.xml以与FastCGI授权器一起使用。
应用程序级别：在您的代码中，始终从最简单的调试输出（例如打印请求环境）开始，然后从那里开始工作。如果要创建一个基本的独立应用程序，请查看Wiki上的瓶子配置。
调试模块内部：如果您仔细检查了上述所有内容，则还可以调试该模块本身的行为。您需要在调试支持（通过./auto/configure --with-debug ... ）中编译Nginx，并且在运行NGINX时，如果您可以在启用调试日志记录的情况下运行NGINX，则最容易。将以下内容添加到您的nginx.conf ：
```
 daemon off ;
error_log stderr debug ;
```
并运行nginx。启动NGINX后，您应该看到包含[调试]的行，并且在提出请求时，控制台记录将继续。如果没有发生，请检查您的NGINX配置和汇编过程。
当您最终提出命中（或应调用） shib_request位置块的请求时，您会在输出中看到类似的行：
```
[debug] 1234 #0: shib request handler
[debug] 1234 #0: shib request set variables
[debug] 1234 #0: shib request authorizer handler
[debug] 1234 #0: shib request authorizer allows access
[debug] 1234 #0: shib request authorizer copied header: "AUTH_TYPE: shibboleth"
[debug] 1234 #0: shib request authorizer copied header: "REMOTE_USER: [email protected]"
...
```
如果您看不到包含SHIB请求的这些类型的行，或者您看到上面的某些行，但没有复制标题/变量的位置，请仔细检查您的NGINX配置。如果您仍然没有任何地方，则可以将自己的调试线添加到源中（遵循此模块的示例），最终确定出了什么问题以及何时出现。如果这样做，请不要忘记每当您进行更改时重新编译Nginx和/或nginx-http-shibboleth 。