Skonfiguruj aplikację Okta do pośredniczenia między naszą aplikacją SP a dostawcą IdP

Question

Jesteśmy dostawcą usług, który ma włączoną funkcję SAML, aby umożliwić dostawcom tożsamości uwierzytelnianie użytkowników. Aby upewnić się, każdy jest na tej samej stronie

• Identity Provider (IDP) jest aplikacją, której zadaniem jest uwierzytelnianie użytkowników
• Service Provider (SP) jest aplikacją koniec, który dokona stowarzyszenia tożsamości i uwierzytelniania IdP
• SAML to protokół pozwalający dostawcom tożsamości na składanie wiarygodnych potwierdzeń tożsamości do SP. Używamy SAML 2.0 (http://en.wikipedia.org/wiki/SAML_2.0)

Więcej informacji o stowarzyszonym tożsamości tutaj: http://developer.okta.com/docs/guides/saml_guidance.html

Obecnie tylko przy użyciu OKTA jak IDP, ale napotkasz sytuacji, w której musimy zintegrować z oddzielną IdP. Chcielibyśmy, aby nasza aplikacja komunikowała się tylko z Okta i mieć Okta do rozmowy z tym oddzielnym dostawcą tożsamości i sprawdzania ich twierdzeń. Ze względu na nasz konkretny przypadek użycia nasza aplikacja wie, jakiego bazowego identyfikatora tożsamości należy użyć, więc nie ma potrzeby wykrywania tożsamości.

Chcielibyśmy skonfigurować OKTA tak, że przepływ uwierzytelniania jest następująca:

1. Nasza aplikacja przekierowuje użytkownika do punktu końcowego w OKTA wskazaniem do używania stanowiącego podstawę IDP do uwierzytelniania

2. Okta a bazowy dostawca tożsamości robi wszystko, co konieczne, aby uwierzytelnić użytkownika i zweryfikować uwierzytelnienie. Nasza aplikacja otrzymuje pojedynczą odpowiedź (przez HTTP-POST) na nasz punkt końcowy ACS, uwierzytelniając użytkownika, podpisany przez OKTA

Z punktu widzenia użytkownika końcowego, to przejdź do service-provider.com, są przekierowywane przez OKTA do underlying-idp.com przeprowadzić uwierzytelnienie niezbędne, a następnie są kierowane z powrotem do usługodawcy .com. Użytkownik końcowy nie jest świadomy średniej warstwy Okta, z wyjątkiem adresu URL Okta wyświetlanego krótko na pasku adresu przeglądarki podczas przekierowań.

Do tej pory udało nam się skonfigurować przychodzący SAML w naszej instancji Okta, aby umożliwić użytkownikom uwierzytelnianie w Okta za pośrednictwem podstawowego dostawcy tożsamości. Przekierowanie naszej aplikacji do punktu końcowego podanego na stronie konfiguracji SAML Inbound przychodzi z parametrem SAMLRequest, ale przenosi użytkowników do pulpitu Okta, ponieważ link służy wyłącznie do uwierzytelniania użytkowników w Okta, a nie do uwierzytelniania użytkowników dla SP za pomocą Okta. Zobacz naszą odpowiednią konfigurację:

• Configuration for our app in Okta which allows us to use Okta as a direct IdP
• Configuration results of the Inbound SAML. We redirect our SAMLRequest to the Assertion Consumer Service URL given

Jak możemy skonfigurować OKTA tak, że nasz przypadek użycia jest możliwe? Idealnie byłoby, gdyby Okta służył jako pośrednik lub mediator, sprawdzając i przekazując żądania/zapewnienia SAML. W szczególności nie potrzebujemy tych użytkowników do uwierzytelniania użytkowników Okta koniecznie; potrzebujemy tylko Okta, by potwierdzić, że użytkownik jest tym, za kogo się podaje, że jest oparty na asercji dostawcy tożsamości.

Answer 1

Wygląda na to, że Kinda potrzebuje możliwości wykrywania IdP, które Okta ma na mapie drogowej jeszcze w tym roku, w połączeniu z ich konfiguracją przychodzących SAML z relacjami z innym dostawcą tożsamości. Wierzę, że można to zaimplementować za pomocą niestandardowej strony logowania. Wspomnieli o tym w profesjonalnych serwisach, ale osobiście poczułbym się o wiele lepiej, gdy na platformę wprowadzono funkcję wykrywania tożsamości.