Atrybut typu Autentykacja OAuth2 – zastosowanie

WEBCON Redaktor Atrybuty,Ogólne
Facebooktwitterpinterestlinkedinmail
Dotyczy wersji: 2021 R1 i powyżej; autor: Łukasz Chechelski

 

Wstęp

Standard uwierzytelniania OAuth2 staję się coraz popularniejszy, pozwalając na integrację między różnymi systemami. W wielu przypadkach połączenie odbywa się w modelu API → Aplikacja, co znacząco ułatwia uwierzytelnianie. W takim przypadku wykorzystywany jest predefiniowany zestaw danych – Client ID, Client Secret, a nasze późniejsze działania autoryzowane są otrzymanym w zamian tokenem.

Co natomiast, kiedy kluczowe jest określenie kontekstu użytkownika? Na tą potrzebę odpowiada atrybut typu Autentykacja OAuth2, który pozwala na uwierzytelnienie użytkownika przed połączeniem się do API i wykonaniem operacji. Opisywany scenariusz opiera się na przedstawieniu tej funkcji przy użyciu komunikacji przez MS Graph z Microsoft Azure. Poruszana konfiguracja swoją tematyką obejmuje:

  • Atrybut typu Autentykacja OAuth2
  • Uwierzytelnianie przez OAuth2
  • MS Graph odpytywany przez wywołania REST.

 

Scenariusz i konfiguracja

W przygotowanym scenariuszu opisana została metoda przerzucenia załącznika z elementu w obiegu do biblioteki SharePoint Online (dalej nazywanego SHO). Założenie jest też takie, iż załadowanie pliku nie będzie odbywało się w kontekście aplikacji, lecz jako użytkownik. W ten sposób po stronie SharePoint Online widoczna będzie informacja o użytkowniku, który wprowadził plik do odpowiedniej biblioteki.

Przy takim scenariuszu działania należy odpowiednio umożliwić uwierzytelnianie użytkownika w panelu administracyjnym Azure Portal. Utworzona tam aplikacja musi legitymować się odpowiednim zestawem uprawnień pozwalającym na zalogowanie użytkownika i wykonanie odpowiednich operacji w SHO. Dobrą praktyką jest określanie niezbędnego minimum uprawnień potrzebnego do wykonania operacji. Uprawnienia poziomu User.Read pozwalają na logowanie, natomiast te z rodziny Sites na operację w obrębie biblioteki SHO.

Rys. 1. Podgląd uprawnień aplikacji w Azure

W kwestii określenia niezbędnego poziomu uprawnień dla aplikacji przydatna okazuje się dokumentacja MS Graph. Zawiera ona skrupulatnie rozpisany zestaw uprawnień, jaki jest wymagany w kontekście wybranych endpointów. Link prowadzący do pełnej dokumentacji znajduje się na końcu artykułu. Poniżej wyciąg dla używanych w naszym przykładzie metod.

Rys. 2. Tabela prezentująca wymagane uprawnienia

Uwagę należy też poświęcić zakładce „Authentication” utworzonej aplikacji. W tym miejscu podawany jest Redirect URI według wzorca:

https://<<BPS_PORTAL_ADDRESS>>/OAuthFlows/ReceiveTokens

 

Rys. 3. Przykładowy Redirect URI

Aby móc poprawnie wykorzystać uzyskany token, na tym samym ekranie należy załączyć możliwość autoryzacji za pomocą tokenów. Do tego służy opcja „Access tokens (used for implicit flows)”. W tym miejscu określa się, czy operacje wykonywane są na pojedynczym tenancie czy w środowisku multitenant.

Rys. 4. Podgląd konfiguracji tokenów

Konfigurację od strony Designer Studio należy rozpocząć od przygotowania autentykacji w zakładce Źródła danych. Dla utworzonej autentykacji typu OAuth2 User -> API należy wybrać szablon Microsoft identity platform (Common). Dzięki tej funkcji system od razu załaduje niezbędną konfigurację. Pozostaje uzupełnienie Client ID oraz Client Secret azurowej aplikacji.

Uwierzytelnianie odbywa się w obrębie zakresów (scopes), zgodnie ze standardem OAuth2. Kolejno na liście powinny znaleźć się:

  • openid
  • email
  • profile

Rys. 5. Konfiguracja autentykacji w Designer Studio

Na podstawie tak utworzonej autentykacji należy utworzyć źródło typu REST Web Service. W jego konfiguracji należy wskazać OAuth2 User -> API jako typ uwierzytelnienia, a następnie wybrać utworzoną autentykację. Ważne jest, aby został podany URL bazowej instancji serwisu: „https://graph.microsoft.com”.

Rys. 6. Konfiguracja źródła w Designer Studio

Następny krok to konfiguracja atrybutu odpowiedzialnego za autentykację użytkownika. Do tego służy pole typu Autentykacja OAuth2. Taki atrybut musi być widoczny w kroku, gdzie użytkownik ma możliwość zalogowania. W konfiguracji zawansowanej jako pierwsze wskazuje się połączenie pozwalające na autentykację. Wśród trybów działania dostępne są trzy opcje:

  • użytkownik – atrybut wyświetla kontrolkę, która pozwala użytkownikowi na zalogowanie się do skonfigurowanego dostawcy uwierzytelnienia, a po zalogowaniu pokazuje użytkownikowi odpowiedni status.
  • JavaScript – w trybie JavaScript kontrolka dla atrybutu nie jest wyświetlana. Działają natomiast wszystkie Reguły formularza (i JavaScript), łącznie z regułą GetToken, pozwalającą programistycznie pobrać token dostępowy wydany podczas uwierzytelniania użytkownika. W tym przypadku autentykacja może odbywać się „w tle”.
  • Użytkownik + JavaScript – stanowi połączenie dwóch powyższych, oferując możliwości zastosowania obu trybów jednocześnie.

Tryb JavaScript sprawdza się w przypadkach, gdzie autentykacja ma być zainicjowana przez Regułę formularza. W tym trybie możliwe jest wykorzystanie funkcji IS AUTHENTICATED oraz AUTHENTICATE. Obie z wymienionych funkcji jako parametr przyjmują atrybut typu Autentykacja OAuth2. Aby upewnić się, że użytkownik nie zapomniał się zalogować, istnieje możliwość osadzenia w parametrach ścieżki poniższego kodu. Dzięki temu zabiegowi użytkownik zostanie poproszony o zalogowanie się w trakcie przejścia ścieżką.

Rys. 7. Przykład użycia funkcji IS AUTHENTICATED oraz AUTHENTICATE

Ciekawa jest też funkcja odnawiania tokenów, którą załączyć można przy użyciu pola znajdującego się bezpośrednio pod zakresami. Jeżeli w trakcie trwania sesji token użytkownika wygaśnie, to funkcja ta pozwala na jego automatyczne odświeżenie. Dzieje się to transparentnie, bez udziału użytkownika.

Jako, że odpowiednie zakresy zostały podane w konfiguracji autentykacji, tutaj nie ma potrzeby powielania wartości. Pole z zakresami pozostaje puste.

Rys. 8. Konfiguracja atrybutu typu Autentykacja OAuth2

Po zapisaniu procesu na formularzu pojawi się nowy atrybut pozwalający na logowanie. Po wybraniu przycisku Zaloguj system połączy się z Azure i wyświetli okno uwierzytelniania. Użytkownik powinien w nim podać dane swojego konta Microsoft.

Rys. 9. Ekran logowania

Po poprawnym zalogowaniu da się zauważyć, że kontrolka zmieni wyświetlane informacje. Mechanizm wspiera autentykację MFA, jeżeli polityka bezpieczeństwa tenanta tego wymaga. Wspierany jest też mechanizm SSO – zalogowany użytkownik nie będzie ponownie proszony o podawanie danych.

Rys. 10. Kontrolka potwierdzająca zalogowanie użytkownika

Możliwe jest wykorzystanie tak skonfigurowanego mechanizmu do uwierzytelnienia w akcji Wywołaj REST Web service.

Komunikacja z SHO odbywa się poprzez MS Graph, którego pryncypium działania opiera się właśnie o ten standard. W zakładce Uwierzytelnianie należy wskazać połączenie – dokładnie to samo, co w kontrolce OAuth2. Dzięki takiemu rozwiązaniu nie ma potrzeby ponownego konfigurowania od podstaw połączenia do MS Graph.

Rys. 11. Konfiguracja akcji Wywołaj REST Web service

W celu przetestowania rozwiązania załącznik zostanie przekazany z elementu obiegu do wskazanej biblioteki. Załącznik przerzucony akcją będzie widniał jako dodany przez konkretnego użytkownika, a nie aplikację. Dlatego też ważne jest, aby użytkownik posiadał odpowiednie uprawnienia także po stronie biblioteki.

Rys. 12. Plik w bibliotece – uwagę zwraca to, że został zmodyfikowany przez użytkownika

Podsumowanie

Atrybut Autentykacja OAuth2 rozbudowuje możliwości integracji WEBCON BPS z różnymi systemami zewnętrznymi. Jego zastosowanie nie ogranicza się jedynie do współpracy z ekosystemem Microsoftu – może on być wykorzystywany wszędzie tam, gdzie wspierany jest standard OAuth2, wliczając np. Google, auth0, czy Keycloak. Jeżeli kluczowe jest wykonywanie operacji w kontekście zalogowanego użytkownika, a nie całej aplikacji, to warto rozważyć implementację opisanego mechanizmu.

Dodatkowe materiały