Opcje integracji i wdrażania PingFederate i NGinx

Question

Jakiś czas wcześniej zaczęliśmy szukać sposobu na integrację PingFederate w naszej infrastrukturze.

Nasz początkowy przypadek użycia jest następujący: zapewniamy dostęp do naszej aplikacji wykwalifikowanemu najemcy, a różne firmy mogą korzystać z różnych (ich) dostawców tożsamości w celu uzyskania dostępu do naszej aplikacji.

Teraz jest ograniczony do tego obiegu przepływu: Mutiple Idp(s) to one SP

Jednak w przyszłych przepływów może zostać przedłużony do Many-to-many relations

Obecnie używamy Nginx jako reverse proxy i na podstawie dokumentacji PingFed to zupełnie trudno poznaj opcje wdrażania, które mamy teraz.

podstawie schematu, który został zabrany z tego guide

jest to bardziej lub mniej jasne, jak ta integracja pracuje apache httpd. Głównie jest to Apache PingFed Agent, który działa z przepływami SSO na apache i głównie sprawdza poprawność "sesji" lub inicjuje przepływ SSO.

Processing Steps 
1. A user attempts to access a resource on the Apache server protected by the PingFederate 
Apache Agent. 
2. The user is redirected to the PingFederate server for authentication. 
(If an OpenToken session already exists, the user is granted immediate access.) 
3. The PingFederate server redirects the user’s browser to an IdP for authentication using either the 
SAML or WS-Federation protocols. The IdP partner authenticates the user and returns a SAML 
assertion. 
4. PingFederate validates the assertion and creates an OpenToken for the user including any 
configured attributes. PingFederate then redirects the browser, including the OpenToken, back to 
the Apache Agent. 
5. The Agent verifies the OpenToken and grants access to the protected resource. The User ID and 
any attributes from the OpenToken are exposed to the resource as HTTP Request Headers or Apache Environment Variables. 

I głównie na Krok 5 środkiem apache przekazuje użytkownikowi informacje na temat rzeczywistej aplikacji przy użyciu nagłówków żądania lub zmiennych Apache środowiskowe.

Na podstawie wszystkich informacji, o którym mowa powyżej jest tu 2 pytania:

1. Jak zrobić podobną instalację dla PingFed i nginx (dla opcji, które opisano w tej kwestii z apache httpd)?
2. Czy wymagane jest używanie serwera WWW (Reverse Proxy) razem z PingFederate. Lub Ping Federate może działać również jako WebServer? Jeśli tak, prawdopodobnie docenione zostaną niektóre linki i dodatkowe wyjaśnienia.

Answer 1

1. Nie ma PingFederate czynnik architektura z Ping Identity że obsługuje nginx. Sugerowałbym zajrzeć do "Adapter bez agenta" (znany również jako adapter odniesienia) i zbudować własny.
2. Nie ma wymogu używania odwrotnego proxy z PingFederate. PingFederate używa Jetty jako swojego kontenera internetowego i jest doskonale nadający się do obsługi ruchu. Dostarczamy opcje odwrotnego proxy , aby wspierać te organizacje, które mają wymagania przed otwarciem portu bezpośrednio na serwerze aplikacji.

Answer 2

warto opublikować ostateczne pomysły na rozwiązanie i nasze obserwacje

1. Kiedy próbowaliśmy zintegrować PingFed mamy rozumieć, że jest bardzo pingFed natywnie zintegrowane z Ping Access. A Ping Access działa jako Reverse proxy.

I główny pomysł, że uwierzytelnianie między PingAccess i PingFed odbywa się za pomocą OpenID Connect protokół.Uwierzytelnianie między PingFederate oraz dostawcy Auth może być wykonana przez bardzo różne sposoby:

1. To może być SAML
2. To może być kolejny ProTool SSO
3. Ping Fed może służyć również strony logowania i dokonać uwierzytelnienia przy użyciu niektórych zwyczaj dB LDAP

Jednakże przepływ uwierzytelniania do stosowania pozostają takie same jak PingFed ukrywa tej złożoności

Answer 3

PingIdentity wydało NGINX certified PingAccess Agent for NGINX servers. Ten agent PingAccess może być wdrożony na serwerze WWW NGINX jako PEP, eliminując w ten sposób potrzeby serwerów proxy.