Jak zostać dostawcą usług SAML


80

Moja firma obecnie opracowuje aplikację internetową w języku Java. Kilku naszych klientów ma wewnętrzne serwery SAML (dostawcy tożsamości?) I poprosili o integrację z nimi. Ostatnio czytałem o tym i bawiłem się z OpenAM. Po około 3 dniach mam ogólne zrozumienie, ale nadal istnieją pewne luki w mojej wiedzy. Mam nadzieję, że ktoś może mi to wyjaśnić.

Oto jak wyobrażam sobie przepływ pracy podczas logowania się użytkownika.

Zdefiniujmy serwer SAML naszych klientów jako https://their.samlserver.com . Tak więc użytkownik przychodzi do naszej aplikacji internetowej w poszukiwaniu chronionego zasobu. Powiedzmy, że adres URL to http://my.app.com/something .

Więc jeśli mam rację, my.app.com jest tym, co SAML definiuje jako dostawcę 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 someBase64Datapowinna być base64zakodowana 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 pytania.

Jaka ma być wartość identyfikatora ?

Dlaczego mogę zadeklarować się jako wystawca ?

Czy dostawca tożsamości wie o mnie? Może to ten krąg zaufania , który widziałem na OpenAM . A jeśli wie o mnie, skąd wie o mnie i co musi wiedzieć?

Więc po przekierowaniu użytkownika do tej strony, jest przenoszony na stronę dostarczoną przez dostawcę tożsamości https://their.samlserver.com . Uwierzytelniają się na tej stronie, a IDP robi magię, aby zweryfikować uwierzytelnienie i wyszukać użytkownika. Po pomyślnym uwierzytelnieniu IDP odsyła <samlp:Response>zdefiniowany tutaj .

Jeszcze kilka pytań.

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

A czego powinienem szukać w tej odpowiedzi, aby potwierdzić, że odniosła sukces? Jak wygląda awaria?

Obecnie używamy adresu e-mail (LDAP) do identyfikowania użytkowników, więc prawdopodobnie wyciągniemy go z odpowiedzi i użyjemy w ten sam sposób, w jaki robimy to teraz. Czy jest coś jeszcze, o czym powinienem pamiętać w tej odpowiedzi?

Teraz, gdy sprawdziliśmy poprawność tej odpowiedzi, możemy przyznać użytkownikowi sesję, tak jak obecnie. Ale kiedy chcą się wylogować, czy istnieje do tego przepływ pracy? Czy muszę powiadomić IDP, że użytkownik odszedł?

I wreszcie, jest kilka tematów, które zostały poruszone w moim czytaniu i nie jestem pewien, jak pasują do tego przepływu pracy. Są to krąg zaufania , żetony i artefakty .

Dziękuję wszystkim za pomoc. W ciągu ostatnich kilku dni znalazłem wiele informacji i możliwe, że uda mi się je poskładać po dłuższej grze. Ale nie znalazłem jeszcze prostego artykułu „Oto post”. Może dlatego, że się mylę co do tego, jak to działa. Może dlatego, że nie jest to tak popularne. Ale naprawdę chciałem się upewnić, że mam przepływ pracy, więc nie przegapiłem kluczowego kroku w czymś tak ważnym, jak uwierzytelnianie użytkownika.


3
Przechodzę teraz przez ten sam problem (sprawdzam, jak utworzyć lekkiego, sfederowanego dostawcę usług SAML v2 współpracującego z tożsamością ping). Czy możesz skomentować, jak to wyszło? Czy skończyłeś używając fedleta lub pisząc własny kod? Dzięki!
theglauber

1
Mam trochę podobne środowisko. Mam aplikację internetową opartą na Javie i uruchomioną na Tomcat. Teraz muszę wykonać logowanie jednokrotne przy użyciu SAML. Nie mam pojęcia o tych technologiach poza wiedzą teoretyczną. Czy ktoś może mi pomóc w konfiguracji od podstaw?
Jerry,

Odpowiedzi:


46

W odpowiedzi na Twoje konkretne pytania:

1.) Jaka powinna być wartość „ID”?

  • Powinien to być unikalny identyfikator żą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 unikalność identyfikatora, pozostaje do implementacji. W przypadku zastosowania techniki losowej lub pseudolosowej, prawdopodobieństwo, że dwa losowo wybrane identyfikatory będą identyczne MUSI być mniejsze lub równe 2 ^ -128, a POWINNO być mniejsze lub równe 2 ^ -160 długości. Wymóg ten MOŻE zostać spełniony przez zakodowanie losowo wybranej wartości o długości od 128 do 160 bitów.

2.) Skąd IdP wie o Tobie?

  • Twój SP musi być zarejestrowany w IdP. Aby to osiągnąć, specyfikacja SAML definiuje format „SAML Metadata”, który informuje dostawcę tożsamości, gdzie znajdują się Twoje odbiorniki SAML, jakie są Twoje certyfikaty, wymieniane atrybuty itp. OpenAM prawdopodobnie określa minimalne wymagania dotyczące konfiguracji zaufanego dostawcy usług. To zależy od produktu.

3.) Gdzie idzie odpowiedź i co sprawdzić?

  • Odpowiedź zostanie przesłana na adres URL usługi Assertion Consumer Service (ACS), który jest zwykle zdefiniowany w metadanych SAML, które wymieniasz między dostawcą usług a dostawcą tożsamości w celu przeprowadzenia początkowej konfiguracji. Po otrzymaniu odpowiedzi SAML musisz sprawdzić wiele rzeczy - ale co najważniejsze, kod stanu SAML powinien mieć wartość „sukces”, identyfikatory inResponseTo powinny być zgodne z wysłanymi w żądaniu i musisz zweryfikować podpis cyfrowy w potwierdzeniu. W tym celu musisz zaufać publicznemu certyfikatowi weryfikacji dostawcy tożsamości, a prawdopodobnie będziesz również chciał sprawdzić odwołania.

4.) A co z wylogowaniem?

  • SAML 2.0 definiuje również profil dla pojedynczego logowania (SLO). Spowoduje to nie tylko wylogowanie z dostawcy usług, ale także dostawcy tożsamości i potencjalnie wszystkich innych dostawców usług, z którymi nawiązałeś sesję. Ma podobny przepływ żądań / odpowiedzi jak jednokrotne logowanie (SSO), a zatem podobne rzeczy do skonfigurowania i sprawdzenia (kody stanu, podpisy itp.).

Krótko mówiąc - wdrożenie tego od podstaw może być dość skomplikowane. Najlepiej jest używać sprawdzonych i prawdziwych bibliotek i / lub produktów, które sugeruje Ian. Firmy takie jak jego zainwestowały setki godzin czasu programisty, aby wdrożyć zgodnie ze specyfikacją i przetestować współdziałanie z innymi dostawcami.


2
Dlaczego w żądaniu SAML powinien znajdować się identyfikator. Nie rozumiem.
Ashwin

1
Jest to wymagane jako część podstawowej specyfikacji SAML 2.0. Zobacz docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf . AuthnRequest jest typu AuthnRequestType (sekcja 3.4.1), który jest rozszerzeniem RequestAbstractType (sekcja 3.2.1), który ma obowiązkowy atrybut ID. Jedną z kluczowych zalet identyfikatora w żądaniu jest to, że odpowiedź może następnie odwołać się do niego, aby SP mógł zmapować te dwa elementy razem, aby zapobiec powtórzeniu.
Scott T.

Mówisz, że identyfikator jest podawany, aby zapobiec atakowi powtórki. Jeśli używam połączenia ssl / https między dostawcą usług a dostawcą IDP, można zapobiec atakowi typu Replay.
Ashwin,

1
SSL / HTTPS między SP i IdP jest nieco bez znaczenia, aby zapobiec atakowi typu replay, ponieważ zwykle używane są wiązania „front channel” (przeglądarki).
Scott T.

@Ashwin - Identyfikator jest tam, więc kiedy otrzymasz odpowiedź, ma ten sam identyfikator i możesz wiedzieć, że odpowiedź, którą otrzymujesz, dotyczyła Twojej prośby, jeśli chodzi o zapobieganie powtórce, rozumiem wiele sygnatur czasowych zarówno w żądaniach, jak i odpowiedziach w SAML i identyfikatorach jest dostępnych tylko w połączeniu z autoryzacją przez ograniczony czas.
Wujek Iroh

3

Jeśli próbujesz ustawić pojedynczą aplikację Java jako dostawcę usług, powinieneś rozważyć użycie Fedletu od Oracle (jako samodzielnego) lub ForgeRock (w pakiecie z OpenAM). Fedlet ForgeRock ma pewne problemy z interakcją z Shibboleth 2.2.1 jako dostawcą tożsamości, ale uważam, że jest to nieco prostsze w konfiguracji i zawiera więcej informacji.

Każdy z nich zawiera wyraźne instrukcje zawarte w pliku README, które ułatwiają wdrażanie. Gdy Fedlet jest skonfigurowany i komunikuje się z dostawcą tożsamości, strona sukcesu pokazuje cały kod potrzebny do zintegrowania sfederowanego logowania jednokrotnego z aplikacją. Wykonuje pracę w tle polegającą na wysyłaniu i odbieraniu żądań autoryzacji i odpowiedzi.

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

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.