nginx http shibboleth 다운로드 nginx http shibboleth 소스 코드 다운로드

nginx http shibboleth

웹사이트 데이터

v2.0.2

다운로드

Nginx에 대한 Shibboleth Auth 요청 모듈

이 모듈을 사용하면 Nginx가 Shibboleth의 FastCGI Austorizer를 통해 Shibboleth와 협력 할 수 있습니다. 이 모듈에는 시스템에서 사용할 수있는 Shibboleth의 FastCGI Austorizer 응용 프로그램뿐만 아니라 올바르게 작동하기 위해 특정 구성이 필요합니다. Shibboleth 권한 및 인증 설정은 웹 서버 구성이 아닌 Shibboleth2.xml을 통해 구성되지만 Apache의 Mod_shib의 일부와 유사합니다.

이 모듈이 location 블록에 대해 구성되면 Shibboleth의 FastCGI 인증자에 대한 하위 퀘스트 결과에 따라 들어오는 요청이 Nginx 내에서 승인됩니다. 이 프로세스 에서이 모듈을 사용하여 성공적인 인증기 응답의 사용자 속성을 Nginx의 원래 요청에 복사하여 백엔드 응용 프로그램에서 사용할 헤더 또는 환경 매개 변수로 복사 할 수 있습니다. 승인이 성공하지 못한 경우 권한있는 응답 상태와 헤더가 클라이언트로 반환되어 액세스를 거부하거나 사용자의 브라우저를 그에 따라 리디렉션합니다 (예 : 구성된 경우 WAYF 페이지에 따라).

이 모듈은 액세스 단계에서 작동하므로 satisfy 지침을 통해 다른 액세스 모듈 (예 : access , auth_basic )과 결합 될 수 있습니다. 이 모듈은 ngx_http_auth_request_module 과 함께 컴파일 할 수 있지만 동일한 location 블록 에서이 모듈을 모두 사용하지 않고 권장되지 않습니다.

아래의 동작에 대해 자세히 알아보고 속성에 헤더를 사용하는 경우 스푸핑을 피하는 데 중요한 메모를 보려면 구성을 참조하십시오.

이것이 전용 모듈 인 이유에 대한 자세한 내용은 https://forum.nginx.org/read.php?2,238523,238523#msg-238523을 참조하십시오.

지침

다음 지침은 Nginx 구성 파일에 추가됩니다. 아래에 언급 된 컨텍스트는 추가 할 수있는 위치를 보여줍니다.

shib_request <URI> | OFF

컨텍스트 : http , server , location

기본값 : off

Shibboleth Auth 요청 모듈을 켜고 승인을 요청하는 URI를 설정합니다. 구성된 URI는 Shibboleth FastCGI 인증자를 가리키는 NGINX 위치 블록을 참조해야합니다.

하위 요청에서 구성된 URI 로의 HTTP 상태 및 응답 헤더는 FASTCGI 권고 자 사양에 따라 사용자에게 반환됩니다. (잠재적으로 중요한) 경고는 Nginx가 현재 서브 퀘스트와 관련하여 현재 작동하는 방식으로 인해 (인증자가 효과적으로 요구하는) 요청 본문은 권한자에게 전달되지 않으며 마찬가지로 권한자의 응답 본문은 클라이언트로 반환되지 않습니다 .

그러나 구성된 URI는 FASTCGI 백엔드를 사용하여 응답을 생성하는 것으로 제한되지 않습니다. Nginx의 return 대가를 사용하여 지시문을 rewrite 하여 적절한 응답을 생성 할 수 있으므로 테스트 중 또는 다른 방법으로 유용 할 수 있습니다. 또한,이 모듈은 FASTCGI 승인자 와 함께 사용될 수 있지만, 위의 경고의 영향을받을 수 있습니다.

경고

shib_request 지시문은 더 이상 shib_authorizer 플래그를 필요로하지 않습니다. Nginx가 시작하려면 제거해야합니다. 다른 변경 사항이 필요하지 않습니다.

shib_request_set <변수> <value>

컨텍스트 : http , server , location

기본값 : none

인증 요청이 완료된 후 variable 지정된 value 으로 설정하십시오. value 인증 요청의 응답의 변수가 포함될 수 있습니다. 예를 들어, $upstream_http_* , $upstream_status 및 nginx_http_upstream_module 문서에 언급 된 기타 변수.

이 지침을 사용하여 Shibboleth 속성을 Backend Application의 환경에 소개하는 데 사용될 수 있으며, 예 : FastCGI PHP 응용 프로그램을위한 $ _server와 같은 권장되는 방법입니다. 예를 들어 구성 문서를 참조하십시오.

shib_request_use_headers on | off

컨텍스트 : http , server , location

기본값 : off

메모

v2.0.0에 추가되었습니다.

Shibboleth Asustrizer 응답의 속성을 기본 요청으로 제목으로 복사하여 업스트림 서버 및 응용 프로그램에서 사용할 수 있도록합니다. shib_request_set 통해 업스트림/응용 프로그램이 서버 매개 변수를 지원하지 않는 경우에만이 옵션을 사용하십시오.

이 설정이 활성화되면 Variable-* 로 시작하는 권한있는 응답 헤더가 추출되어 헤더 이름에서 Variable- 하위 문자열을 제거하고 백엔드로 전송되기 전에 기본 요청으로 복사합니다. 예를 들어, Variable-Commonname: John Smith 와 같은 권한있는 응답 헤더는 Commonname: John Smith 기본 요청에 추가되어 백엔드로 전송됩니다.

스푸핑을 조심하십시오 - 백엔드 응용 프로그램이 헤더 주입으로부터 보호되어야합니다. 이를 달성하는 방법에 대한 구성 예제를 참조하십시오.

설치

이 모듈은 Nginx 1.9.11에 동적 모듈을 도입하기 때문에 정적으로 또는 동적으로 컴파일 될 수 있습니다. 동적 모듈의 실질적인 상향은 영구적으로 존재하고 활성화 된 정적 모듈과 달리로드 될 수 있다는 것입니다.

이 모듈의 패키지 버전을 얻는 가장 쉬운 방법은 NGINX에서 PKG-SOSS 도구를 사용하는 것입니다. NGINX에서 PKG-SOSS 도구를 사용하는 것입니다.이 모듈은 주요 리포지토리에서 NGINX의 공식 릴리스와 함께 설치를위한 동적 모듈의 포장을 제공하며 NGINX를 수작업으로 컴파일 할 필요가 없습니다.

그렇지 않으면,이 모듈로 Nginx를 동적으로 컴파일하려면 nginx를 구축 할 때 다음 옵션을 ./configure 로 전달하십시오.

 --add-dynamic-module = <path>

다음을 포함하여 nginx.conf 에 모듈을 명시 적으로로드해야합니다.

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

및 Nginx를 다시로드 또는 다시 시작합니다.

이 모듈로 Nginx를 정적으로 컴파일하려면 Nginx를 구축 할 때 다음 옵션을 ./configure 로 전달하십시오.

 --add-module = <path>

정적 빌드를 사용하면 모듈이 Nginx에 내장되어 있으므로 추가 로딩이 필요하지 않습니다.

구성

nginx/shibboleth 환경 구성에 대한 자세한 내용은 https://github.com/nginx-shib/nginx-http-shibboleth/blob/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;
}

우리는 헤더를 More-Nginx 모듈을 사용하여 잠재적으로 위험한 입력 헤더를 제거하고 스푸핑의 가능성을 피합니다. 환경 변수의 후자의 예는 백엔드가 환경 매개 변수 에서만 데이터를 읽는 한 헤더 스푸핑에 취약하지 않습니다.

Shibboleth Austorizer에서 기본 헤더를 지우기 위해 기본 구성을 사용할 수 있지만 응용 프로그램에서 사용하는 모든 속성에 대한 명확한 지시문을 작성해야합니다. 일부 응용 프로그램은 환경에서 Shibboleth 속성을 읽은 다음 헤더로 돌아 가려고하므로 shib_request_use_headers 사용하지 않더라도 응용 프로그램의 코드를 검토합니다.

shib_request_set 사용하면 모든 Core Shibboleth 변수가 FastCGI 인증기에서 응용 프로그램으로 전달되도록 NGINX include 사용할 수있는 기본 매개 변수 파일을 사용할 수 있습니다. 수많은 기본 속성이 포함되므로 응용 프로그램에 필요하지 않은 속성을 제거하고 필요한 연맹 또는 IDP 속성을 추가하십시오. 이 기본 매개 변수 파일은 fastcgi_param 지시문을 uwsgi_param , scgi_param 등으로 변경함으로써 FASTCGI가 아닌 업스트림에 대해 재사용 할 수 있습니다.

Gotchas

Shibboleth Auth 요청과 같은 하위 퀘스트는 헤더 필터를 통해 처리되지 않습니다. 이는 add_header 와 같은 내장 지시문이 A /shibauthorizer 블록의 일부로 구성된 경우 작동 하지 않음을 의미합니다. 하위 수익 헤더를 조작 해야하는 경우 모듈 headers-more 에서 more_set_headers 사용하십시오.
https://forum.nginx.org/read.php?29,257271,257272#msg-257272를 참조하십시오.

행동

이 모듈은 가능한 경우 FASTCGI 인증자 사양을 따르지만 그 이유가있는 몇 가지 주목할만한 편차가 있습니다. 따라서 행동은 다음과 같습니다.

권한있는 서브 퀘스트는 원래 요청의 모든 측면으로 구성되며, 요청 본문을 제외하고 Nginx는 요청 본문의 버퍼링을 지원하지 않기 때문입니다. Shibboleth FastCGI 인증자가 요청 본문을 고려하지 않기 때문에 이것은 문제가되지 않습니다.
권한있는 서브 퀘스트가 200 상태를 반환하면 액세스가 허용됩니다.
shib_request_use_headers 활성화되고 Variable-* 로 시작하는 응답 헤더가 추출되고 헤더 이름에서 Variable- 하위 문자열을 제거하고 기본 요청으로 복사합니다. Variable- 으로 접두사가없는 다른 권한있는 응답 헤더 및 응답 본문은 무시됩니다. FASTCGI 사양은 FASTCGI 환경에 Variable-* 이름 값 쌍이 포함되도록 요구하지만, 우리는 Backend (예 : proxy_pass )와 함께 사용될 수 있도록 헤더를 만들고 FastCGI 애플리케이션으로 제한하는 것이 아닙니다. Variable-* 데이터를 대신 헤더로 전달하면 Apache 용 mod_shib 에서 ShibUseHeaders On 의 동작에 따라 이러한 사용자 속성을 헤더로 전달합니다.
속성을 환경 변수 ( mod_shib 의 ShibUseEnvironment On 와 동일)로 전달하려면 각 속성에 대해 shib_request_set 지시문을 사용하여 속성을 수동으로 추출해야합니다. 각 백엔드는 다른 방식으로 매개 변수를 수락 할 수 있으므로 모든 속성에 대해 (현재) 대량으로 수행 할 수는 없습니다 ( fastcgi_param , uwsgi_param 등). 풀 요청은이 동작을 자동화 할 수 있습니다.
권한있는 서브 퀴즈가 다른 상태 (리디렉션 또는 오류 포함)를 반환하면 권한있는 응답의 상태 및 헤더가 클라이언트로 반환됩니다.
이는 401 Unauthorized 또는 403 Forbidden 액세스가 거부되고 승인자의 헤더 (예 : WWW-Authenticate )가 고객에게 전달 될 것임을 의미합니다. 다른 모든 권한있는 응답 (예 : 3xx 리디렉션)은 상태 및 헤더를 포함하여 클라이언트에게 다시 전달되므로 Wayf 페이지 및 Shibboleth Responder ( Shibboleth.sso )와 같은 리디렉션이 올바르게 작동합니다.
FASTCGI 승인자 사양은 응답 본문을 클라이언트로 반환 할 것을 요구하지만 NGINX는 현재 버퍼링 하위 퀘스트 응답 ( 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 에서 호스팅되는 Shibboleth.sso)에게는 적용되지 않습니다 . 이는 FastCGI 응답자이며 Nginx는 하위 수단이 사용되지 않기 때문에 이것과 완전히 호환됩니다.
자세한 내용은 https://forum.nginx.org/read.php?2,238444,238453을 참조하십시오.

이 모듈은 Shibboleth의 FastCGI 인증기를 위해 특별히 준비되어 있지만 위의 사양과의 편차를 염두에두고 다른 승인자와 함께 작동 할 것입니다.

테스트

새로운 커밋이 리포지토리에 또는 새로운 풀 요청이 열릴 때마다 테스트는 GitHub 작업 (이 구성 사용)에서 자동으로 실행됩니다. 무언가가 끊어지면, 당신은 알게되며 결과는 Github 에보 고됩니다.

테스트는 다른 버전과 Nginx의 구성 및 Test :: NGINX PERL 테스트 스캐 폴딩을 구성하여 모듈을 컴파일하기위한 간단한 bash 스크립트의 조합을 사용하여 작성됩니다. 테스트를 확장하는 방법에 대한 정보는 이전 링크를 참조하고 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 또는 웹 서버 설정에 대한 지원 요청은 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 버전을 사용하거나 다른 타사 모듈을 사용하는 경우 위의 테스트 스위트를 실행하여 호환성을 확인해야합니다. 테스트가 실패하면 구성을 확인하거나 NGINX 버전 업데이트를 고려하십시오.
Shibboleth 구성 : shibboleth2.xml 및 관련 구성을 확인하여 호스트, 경로 및 속성이 올바르게 해제되는지 확인하십시오. 예제 구성을 사용하면 shibboleth2.xml FASTCGI 인증자와 함께 작동하도록 Key "GOTCHA"를 식별하는 데 도움이 될 수 있습니다.
응용 프로그램 수준 : 코드 내에서 항상 가장 간단한 디버깅 출력 (예 : 요청 환경 인쇄)부터 시작하여 거기서 작업하십시오. 기본적이고 독립형 앱을 만들려면 Wiki의 병 구성을 살펴보십시오.
디버깅 모듈 내부 : 위의 모든 것을주의 깊게 확인한 경우이 모듈 자체의 동작을 디버깅 할 수도 있습니다. 디버깅 지원 ( ./auto/configure --with-debug ... )을 통해 nginx를 컴파일해야하며 nginx를 실행할 때 디버그 로깅을 활성화 한 상태에서 전경에서 실행할 수있는 것이 가장 쉽습니다. nginx.conf 에 다음을 추가하십시오.
```
 daemon off ;
error_log stderr debug ;
```
그리고 nginx를 실행합니다. Nginx를 시작하면 [디버그]가 포함 된 라인이 표시되며 요청을 받으면 콘솔 로깅이 계속됩니다. 이런 일이 발생하지 않으면 Nginx 구성 및 컴파일 프로세스를 확인하십시오.
결국 shib_request 위치 블록을 조회하거나 호출 해야하는 요청을 할 때는 출력에 SO와 같은 선이 표시됩니다.
```
[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 다시 컴파일하는 것을 잊지 마십시오.