Jednym z punktów migracji klienta do Amazon Web Services było włączenie SSO (Single Sign On) – co jest bardzo wygodnym rozwiązaniem. Po szybkiej weryfikacji (jakie mamy możliwości), okazało się, że możemy użyć ADFS. Klient już wykorzystywał ADFS pod inne usługi, zatem mogliśmy pominąć etap przekonywania Security Team.
Po kilku dniach walki z różnymi zawiłościami Ping Federate udało się włączyć SSO, zrobić ładną pętlę przekierowań przez wspomnianego ADFS. Zwracany SAML miał wszystko czego potrzebujemy, a Windchill na to odpowiedział… „Error 500”.
Bardziej dogłębna lektura dokumentacji ujawniła, że SSO z ADFS jest jak najbardziej przez Windchilla wspierane, ale tworzenie nowego użytkownika na podstawie otrzymanego z ADFS SAML’a już nie. Windchill potrzebuje bazy użytkowników do porównania, a to najwygodniej dostarczyć odpytując kontroler domeny jakimś ldap’em, jeszcze lepiej z SSL.
Wystawienie kontrolera na świat raczej nie przejdzie przez Security Team, a przecież musimy je jakoś odpytać.
Trzeba się spiąć z klientem VPN i przez tunel odpytywać kontrolery bezpiecznym ldaps. Niestety, żeby nie było tak prosto, to w AWS już kilka środowisk działa, każde w innym VPC i każde musi się dostać ze swoim zapytaniem do AD.
Wariantów było wiele (to tylko kilka):
Niestety, istniejące już VPC pokrywały się adresami z tym, co klient miał w swojej sieci. Oczywiście dałoby się to obejść, natomiast naglił nas czas, a zabawy z routingiem w globalnej organizacji mogły ciągnąć się latami.
Krótka prezentacja (która naświetliła klientowi problem), zaowocowała wypracowaniem stanowiska, że tworzymy nowe VPC, robimy routing, peering między pozostałymi VPC, łączymy VPN i stawiamy w tym VPC AWS Directory Service.
Tak też było, ale niestety okazało się, że ograniczenia tego ostatniego nie bardzo pozwalają na odpytywanie protokołem ldap o obiekty w domenie klienta. Tak – mała porażka… Nie wspominając już o ustawiania Trust Relationship między domenami.
W między czasie, żeby nie blokować developmentu jakiegoś dodatkowego narzędzia, wystawiliśmy w VPC zwykłego Amazon Linux i prostym tunelem SSH ominęliśmy kilka ograniczeń związanych z brakiem tranzytowych VPC w AWS.
Kolejnym podejściem było wystawienie w AWS Kontrolera domeny klienta w trybie tylko do odczytu. Takie rozwiązanie zapewniało dostęp do aplikacji nawet w przypadku problemów z tunelami VPN. Zorganizowanie VPN poszło nadspodziewanie dobrze.
Już myśleliśmy, że jesteśmy blisko: kontroler tylko do odczytu, dało się go odpytać ldap i wszystko było pięknie, ale nie dla Security klienta, które wcześniej zgodziło się na taką opcje. Co poradzić, Security wie swoje i klucza publicznego do wewnętrznego CA nam nie dadzą – ehh te PKI.
Niesieni pewną emocją, uznaliśmy, że dość już tego pięknego tańca. Szybki przegląd stanu:
Czegoś na kształt proxy ldap do Active Direcotry. Stawiamy VPC z VPN, ciskamy zapytaniami ldap w to proxy, następnie ono nas gładko przekierowało do AD klienta i byliśmy w domu.
Kolejne 5 godzin prób i TAADAAM – działa. OpenLDAP daje radę. Weryfikacja w Windchillu i po problemie. EC2 z OpenLdap działa i… w zasadzie to się nudzi.
Hmm, a może by tak to wsadzić w kontener docker?
Hmm, a może by ten kontener uruchomić w ECS?
Hmm, w sumie persistent storage to nie potrzebuje, to może Fargate?
Zbudowanie kontenera z LDAP Proxy na z CentOS to w sumie kilka linijek. Potem szybki upload do ECR, definicja Taska i można tworzyć serwis.
Tylko jak kierować ruch na ten serwis? Przecież IP będzie za każdym razem inny. Może przez LoadBalancer? – nie.
Definiując Serwis można użyć opcji „Service Discovery”, która to opcja tworzy Hosted Zone w Route53 i aktualizuje rekord A prowadzący do serwisu – genialne. Teraz tylko wystarczy taką Hosted Zone przypiąć do VPC z Windchillem i strzelać zapytania ldaps do zarejestrowanej tam nazwy.
Na koniec (żeby się specjalnie później tym nie interesować) wystarczy zdefiniować prosty healthcheck, dzięki któremu ECS będzie podmieniał nam niedziałający kontener na nowy – zwykle w ciągu minuty.
