Jak zostać dostawcą usług SAML

Dzień Dobry Wszystkim,]}

Moja firma obecnie rozwija aplikację internetową Java. Kilku naszych klientów ma wewnętrzne serwery SAML (dostawcy tożsamości?) i zażądali integracji z nimi. Ostatnio czytałem o tym i bawiłem się OpenAM. Po około 3 dniach od tego mam ogólne zrozumienie tego, ale nadal są pewne luki w mojej wiedzy. Mam nadzieję, że ktoś mi to wyjaśni.

Oto jak sobie wyobrażam przepływ pracy użytkownik logujący się.

Zdefiniujmy naszych klientów SAML server jako https://their.samlserver.com . więc użytkownik przychodzi do naszej aplikacji internetowej po zasób, który jest chroniony. Załóżmy, że adres URL to http://my.app.com/something .

Więc jeśli mam rację, my.app.com to jest to, co SAML definiuje jako dostawca usług . Nasza aplikacja zdaje sobie sprawę, że ten użytkownik musi się zalogować. Następnie przedstawiamy użytkownikowi taką stronę...

<script>JQuery Script to auto submit this form on ready</script>
<form method="post" action="https://their.samlserver.com/Post/Servlet">
    <input type="hidden" name="SAMLRequest" value="someBase64Data" />
    <input type="submit" value="Submit" />
</form>

I to someBase64Data powinna być base64 zakodowana wersja tego...

<samlp:AuthnRequest
  xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
  xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
  ID="identifier_1"
  Version="2.0"
  IssueInstant="2004-12-05T09:21:59Z"
  AssertionConsumerServiceIndex="0">
 <saml:Issuer>http://my.app.com</saml:Issuer>
 <samlp:NameIDPolicy
   AllowCreate="true"
   Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"/>
</samlp:AuthnRequest>

Więc moje pierwsze kilka pytań.

Jaka jest wartość ID ?

I dlaczego mogę się zgłosić jako Emitent ?

Czy dostawca tożsamości wie o mnie? Może to jest ten krąg zaufania

Widziałem na OpenAM . A jeśli wie o mnie, to skąd wie o mnie i co musi wiedzieć?

Więc po użytkowniku jest przekazywana tej stronie, są one przenoszone na stronę dostarczoną przez IDP https://their.samlserver.com. uwierzytelniają się na tej stronie, a IDP sprawdza uwierzytelnienie i wyszukuje użytkownika. Po pomyślnym uwierzytelnieniu IDP odsyła <samlp:Response> zdefiniowane tutaj.

Jeszcze kilka pytań.

Po pierwsze, w jaki sposób <samlp:Response> wróci do mojej aplikacji internetowej, abym mógł ją sprawdzić?

A czego powinienem szukać w odpowiedź potwierdzająca, że się powiodła? Jak wygląda porażka?

Obecnie używamy adresu e-mail (LDAP) do identyfikacji użytkowników, więc prawdopodobnie pobierzemy go z odpowiedzi i użyjemy go w taki sam sposób, jak teraz. Coś jeszcze powinienem pamiętać w tej odpowiedzi?

Więc teraz, gdy sprawdziliśmy tę odpowiedź pod kątem ważności, możemy przyznać użytkownikowi sesję, tak jak to robimy obecnie. Ale kiedy chcą się wylogować, czy istnieje do tego przepływ pracy? Czy muszę powiadomić IDP, który opuścił użytkownik?

I wreszcie, jest kilka tematów, które zostały rzucone wokół w mojej lekturze i nie jestem pewien, jak one pasują do tego przepływu pracy. Są krąg zaufania, tokeny i artefakty .

Dzięki za pomoc. Znalazłem wiele informacji w ciągu ostatnich kilku dni, i jest możliwe, że mógłbym je poskładać po trochę więcej gry. Ale jeszcze nie znalazłem prostego " Oto Post" jeszcze artykuł workflow. Może dlatego, że mylę się co do tego, jak to działa. Może dlatego, że to nie jest zbyt popularne. Ale naprawdę chciałem się upewnić, że mam przepływ pracy, aby nie przegapić kluczowego kroku w czymś tak ważnym, jak uwierzytelnianie użytkowników.
Author: Simeon Leyzerzon, 2011-03-31

2 answers

W odpowiedzi na twoje konkretne pytania:

1.) Jaka ma być wartość "ID"?

  • powinien to być niepowtarzalny identyfikator dla żądania SAML. Specyfikacja SAML 2.0 stwierdza, że jest to naprawdę specyficzne dla implementacji, ale zawiera następujące zalecenia:]}

Mechanizm, za pomocą którego jednostka systemu SAML zapewnia, że identyfikator jest unikalny jest pozostawiony do implementacji. W przypadku, gdy losowe lub stosuje się technikę pseudorandomową, prawdopodobieństwo dwóch losowo wybrane identyfikatory, które są identyczne, muszą być mniejsze lub równe do 2 ^ -128 i powinna być mniejsza lub równa 2 ^-160 długości. Wymóg ten może być spełniony przez kodowanie losowo wybranej wartości od 128 do 160 bitów długości.

2. Skąd IdP o tobie wie?

  • twój SP musi być zarejestrowany w IdP. W tym celu Specyfikacja SAML definiuje format dla "Metadane SAML", które informują IdP, gdzie są Twoje odbiorniki SAML, jakie są Twoje certyfikaty, atrybuty, które wymieniasz itp. OpenAM prawdopodobnie dyktuje pewne minimalne wymagania dotyczące konfiguracji trusted SP. To różni się w każdym produkcie.

3. Gdzie jest Odpowiedź i CO sprawdzić?

  • odpowiedź trafi do Twojego adresu URL Assertion Consumer Service (ACS) Zwykle zdefiniowanego w metadanych SAML, które wymieniasz z SP z IdP w celu wstępnej konfiguracji. Kiedy ty otrzymaj odpowiedź SAML, musisz sprawdzić wiele rzeczy - ale co najważniejsze, kod statusu SAML powinien być "sukces", identyfikatory inResponseTo powinny pasować do wysłanych żądań i musisz potwierdzić podpis cyfrowy na twierdzeniu. W tym celu musisz zaufać certyfikatowi weryfikacji publicznej IdP i prawdopodobnie będziesz również chciał sprawdzić odwołanie.

4.) A co z wylogowaniem?

  • SAML 2.0 definiuje również profil dla pojedynczego wylogowania (Slo). Spowoduje to nie tylko wylogowanie cię z SP, ale także IdP i potencjalnie wszelkie inne SP, z którymi utworzyłeś sesję. Ma podobny przepływ żądania / odpowiedzi jak Single Sign-On (SSO), a więc podobne rzeczy do skonfigurowania i sprawdzenia (kody statusu, sygnatury itp.).

W skrócie-może to być dość skomplikowane do wdrożenia od podstaw. Najlepiej używać sprawdzonych bibliotek i / lub produktów, jak sugeruje Ian. Firmy takie jak on zainwestowały setki godzin czasu dewelopera wdrożenie zgodnie ze specyfikacją i przetestowanie interoperacyjności z innymi dostawcami.

 43
Author: Scott T.,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2018-07-24 17:17:10

Jeśli próbujesz skonfigurować pojedynczą aplikację Java jako dostawcę usług, powinieneś rozważyć użycie Fedleta z Oracle (jako samodzielny ) lub ForgeRock (w pakiecie z OpenAM ). ForgeRock Fedlet ma pewne problemy z Shibboleth 2.2.1 jako dostawcą tożsamości, ale uważam, że jest nieco prostszy w konfiguracji i bardziej pouczający.

Każdy zawiera wyraźne instrukcje zawarte w README, które pomogą Ci wdrożyć. Gdy Fiedlet jest skonfigurowana i komunikująca się z IDP strona sukcesu pokazuje cały kod potrzebny do zintegrowania federacyjnego SSO z aplikacją. Wykonuje pracę w tle wysyłania i odbierania zapytań i odpowiedzi Authn.

Odpowiedź Scotta dość dobrze odpowiada na twoje pytania, ale myślę, że próba samodzielnego napisania kodu, który generuje SAML, to wymyślanie koła na nowo. Zasilacz został zaprojektowany dokładnie z myślą o tym przypadku użycia.

 2
Author: user538917,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-04-17 21:50:04