3 minute read

poprzednim artykule wspomniałem, że następny wpis poświęcę opisowi integracji API Management  z Azure Active Directory. Dzisiaj postaram się szybko opisać proces konfiguracji i pokazać Ci kilka ciekawych opcji związanych z zarządzaniem tożsamością w usłudze.

Logowanie do Developer Portalu przez AAD

Na wstępie warto zaznaczyć, że domyślną formą logowania dla deweloperów do API Management jest local account. W skrócie każdy z deweloperów ma możliwość założenia konta w oparciu o konto email. W zależności od ustawień możemy wszystkich anonimowych (niezalogowanych) użytkowników przekierować na stronę logowania, zmuszając ich tym sposobem do rejestracji.

Jeżeli Wasz API Management będzie głównie używany wewnętrznie w organizacji, a nie przez osoby z zewnątrz, dość szybko zgłoszą się do Was smutni panowie z InfoSec z prośbą, by dostęp do portalu możliwy był tylko w oparciu o firmowe konta. Nie ukrywam, że jestem zdecydowanym zwolennikiem takiego podejścia, które ma sporą ilość zalet:

  • Hasło podlega politykom zarządzanym przez administratorów
  • Mamy możliwość podpięcia MFA
  • Mamy możliwość korzystania z SSO
  • Kiedy opuścimy naszą firmę automatycznie tracimy dostęp do usługi wraz z wyłączeniem konta organizacyjnego

W związku z faktem, że poruszamy się w świecie Microsoft Azure, dość oczywistym wyborem jest właśnie integracja z Azure Active Directory. Niestety opcja ta jest dostępna jedynie w wersji Developer oraz Premium naszego API Management. Sporo osób narzeka na to ograniczenie, ale są szanse na zmiany w przyszłości (np dodanie nowego wariantu usługi).

Proces integracji jest dość dobrze opisany tutaj, na uwagę zasługują dwie rzeczy:

  • Czytając dokumentację można odnieść wrażenie, że aplikację w AAD należy stworzyć w starym portalu. Oczywiście nowy portal jest w zupełności wystarczający. Ten wpis pewnie Ci trochę w tym pomoże.
  • Przy tworzeniu aplikacji AAD musimy nadać jej dwa scope, User.Read oraz Directory.Read.All. Drugi stanowi pewien problem, ponieważ jest uprawnieniem bezpośrednim i wymaga zgody administratora naszego AAD. Musimy go przekonać, by zezwolił API Management na buszowanie po liście użytkowników i grup.

img

Zarządzanie widocznością API przy pomocy grup AAD

Jeżeli udało Ci się zakończyć powyższe kroki członkowie domeny będą mogli się rejestrować i logować do API Management przy pomocy swoich kont służbowych. Nie zapomnij wyłączyć rejestracji przez local account!

W związku z tym, że APIM może pobierać informacje o grupach w AAD (Directory.Read.All), dostajemy nową funkcję.  Wreszcie możemy dodawać nowe role (poza trzema wbudowanymi, opisanymi w moim poprzednim artykule). Tym sposobem część API lub produktów jesteśmy w stanie opublikować dla wybranych grup użytkowników.  Z kolei członkostwo w grupach zarządzane jest z poziomu AAD, lub nawet samego on-premises AD, jeśli zdecydowaliśmy się wcześniej na takie podejście. Oczywiście członkiem grupy może być inna grupa, co daje nam całkiem dużą elastyczność.

Inne źródła tożsamości w API Management

Poza local account i AAD usługa pozwala również skonfigurować dostęp przy pomocy kont społecznościowych (Facebook, Twitter, Google+, Microsoft Account). Na szczególną uwagę zasługuje jednak moja ulubiona usługa, szwajcarski scyzoryk jeśli chodzi o tożsamość – Azure AD B2C.

Użycie B2C nie oznacza jedynie, że możemy dać dostęp do APIM naszym klientom zewnętrznym. Przy pomocy Identity Experience Framework i custom policies, mamy praktycznie nieskończone możliwości:

  • Możemy zintegrować w B2C kilka tenantów AAD
  • Podpiąć się pod firmowego ADFSa
  • wspierany, ale u mnie działa).
  • Zebrać przy rejestracji dodatkowe informacje
  • Umożliwić rejestrację tylko na mailowe zaproszenie (link aktywacyjny)
  • I wreszcie, skombinować to co powyżej i wiele, wiele więcej w rozwiązanie spełniające wszystkie nasze potrzeby

Tak przy okazji, IEF w B2C nie należy do rzeczy najprostszych. Mam kilka pomysłów na wpisy na blogu w tym temacie, ale zanim to zrobię, chciałbym się dowiedzieć, czy ktokolwiek jest tym tematem zainteresowany! Będę wdzięczny za wszelkie komentarze 🙂

Tymczasem już dziś zapraszam Cię do następnego wpisu o APIM. Wspólnie dodamy pierwsze API i postaramy się je poprawnie zabezpieczyć.

Photo credit: Got Credit via Visualhunt.com / CC BY

Comments