Korzystanie z uwierzytelniania opartego na protokole OAuth 2.0 w przypadku aplikacji klienckich
Protokół Open Authorization (OAuth) 2.0 opisuje sposoby, w jakie właściciel zasobów może nadać dostęp do chronionych zasobów. Produkt IBM® Cloud Pak for Business Automation as a Service obsługuje tylko typ nadania hasła właściciela zasobu (ROPC) na potrzeby uwierzytelniania dostępu aplikacji klienckiej do środowiska chmury.
Typ nadania ROPC
W przypadku protokołu OAuth 2.0 aplikacje klienckie Cloud Pak for Business Automation as a Service są klientami poufnymi. W przypadku typu nadania ROPC wymagają one zestawu referencji klienta (składających się z identyfikatora klienta i klucza tajnego klienta) oraz nazwy użytkownika i hasła właściciela zasobu. Aby uzyskać informacje autoryzacyjne klienta, należy wygenerować je za pomocą interfejsu API produktu Credentials . W przypadku nazwy użytkownika i hasła zaloguj się do portalu w chmurze jako administrator konta, wygeneruj zestaw referencji usługi, a następnie przypisz tym referencjom uprawnienia wymagane przez aplikację kliencką. Uprawnienia są używane w opartej na znacznikach OAuth 2.0 kontroli dostępu do środowisk w chmurze.
Więcej informacji na temat protokołu OAuth i typu nadania ROPC zawiera sekcja Środowisko autoryzacji OAuth 2.0. Więcej informacji na temat interfejsu API produktu Credentials zawiera sekcja Przykład: Informacje autoryzacyjne REST API dla uwierzytelniania opartego na protokole OAuth 2.0 oraz informacje o uzyskiwaniu referencji usługi, patrz sekcja Tworzenie kont usług i zarządzanie nimi.
Zarządzanie referencjami klienta OAuth 2.0
Klienty OAuth 2.0 muszą udostępnić referencje klienta, aby zidentyfikować wywoływanie kontekstu klienta. Możesz decydować o liczbie wymaganych zestawów referencji. Na przykład możesz używać jednego zestawu dla wszystkich klientów OAuth 2.0 lub mieć osobny zestaw referencji dla każdego klienta.
- Uzyskiwanie znacznika dostępu OAuth 2.0.Punkt końcowy /token protokołu OAuth 2.0 umożliwia uzyskanie tokenu dostępu, w tym klienta (identyfikator klienta i klucz tajny klienta) oraz informacji autoryzacyjnych usługi (nazwa użytkownika i hasło). Na przykład:
Wywołanie zwraca znacznik dostępu (do wykorzystania w kolejnych wywołaniach interfejsu API operacji w chmurze), znacznik odświeżania (do odświeżania znacznika dostępu) oraz okres ważności znacznika dostępu. Należy pamiętać, że znaczniki dostępu są zwykle ważne przez podaną liczbę minut lub godzin, podczas gdy znaczniki odświeżania mogą być ważne przez podaną liczbę dni. Zasięg nie jest obsługiwany.curl -k -v -X POST -H 'content-type: application/x-www-form-urlencoded' -d grant_type=password -d client_id=<clientId> -d client_secret=<clientSecret> -d username=<serviceCredId> -d password=<svcCredSecret> https://www.bpm.ibmcloud.com/mga/sps/oauth/oauth20/token
Jeśli wywołanie powiedzie się, jest zwracany kod odpowiedzi HTTP 201. Jeśli informacje autoryzacyjne klienta lub usługi są niepoprawne, wywołanie zwróci kod odpowiedzi HTTP{"access_token":"CJ7yDymDAfSRz03W7zdX","refresh_token":"fGAv2qzuLnM030Brs8KFaIuY1Kd2P87sLFXI85lH","scope":"","token_type":"bearer","expires_in":1799}*BAD_REQUEST (400). - Używanie znacznika do uzyskiwania dostępu do interfejsów API operacji w
chmurze.Zwrócony znacznik dostępu z poprzedniego kroku należy dołączyć do nagłówka autoryzacji wywołania interfejsu API operacji w chmurze. Na przykład:
Jeśli znacznik dostępu jest niepoprawny lub utracił ważność, wywołanie zwróci kod odpowiedzi HTTP 302.curl -k -v -H "Authorization: Bearer CJ7yDymDAfSRz03W7zdX" https://<tenantHost>/baw/dev/rest/bpm/wle/v1/user/current - Odświeżanie znacznika dostępu przy użyciu znacznika odświeżania.Użyj punktu końcowego /token protokołu OAuth 2.0.
Wywołanie zwraca nowy zestaw znaczników.curl -k -v -X POST -H 'content-type: application/x-www-form-urlencoded' -d grant_type=refresh_token -d refresh_token=fGU3UjAHG0XKTdnInU8ihqTLf48XJIzQtRUjNFVo -d client_id=<clientId> -d client_secret=<clientSecret> https://www.bpm.ibmcloud.com/mga/sps/oauth/oauth20/token
Wywołanie zwraca kod odpowiedzi HTTP{"access_token":"DkhN7gg7mk2gsBjGi8ay","refresh_token":"ToY13V2yfoYaeVbBjTwFLhzwX7GiKd7Y801VfjGC","scope":"","token_type":"bearer","expires_in":1799}BAD_REQUEST (400), jeśli znacznik odświeżania jest niepoprawny lub został już użyty, lub jeśli referencje klienta są niepoprawne, na przykład dlatego, że zostały usunięte. - Unieważnianie znacznika odświeżania i znacznika dostępu na zakończenie
przetwarzania aplikacji klienckiej.
Po zakończeniu przetwarzania aplikacji klienckiej zaleca się unieważnienie obu znaczników za pomocą punktu końcowego /revoke protokołu OAuth 2.0. Przed unieważnieniem znacznika dostępu należy unieważnić znacznik odświeżania.
Na przykład w celu unieważnienia znacznika odświeżania można użyć następującego wywołania:
Wywołanie zawsze zwraca kod odpowiedzi HTTP oznaczający powodzenie (np. 200).curl -k -v -X POST -H 'content-type: application/x-www-form-urlencoded' -d client_id=<clientId> -d client_secret=<clientSecret> -d token=ToY13V2yfoYaeVbBjTwFLhzwX7GiKd7Y801VfjGC https://www.bpm.ibmcloud.com/mga/sps/oauth/oauth20/revokeUwaga: Po uzyskaniu dostępu do interfejsu API token dostępu pozostaje ważny do czasu jego utraty ważności.
Ograniczenia
W całym systemie obowiązuje dzienny limit kilkuset jednocześnie ważnych uprawnień (par znaczników dostępu i odświeżania). Uprawnienia są identyfikowane na podstawie aplikacji klienckiej i nazwy użytkownika właściciela zasobu. Oczekuje się, że limit uprawnień nigdy nie zostanie osiągnięty. Jeśli jednak zostanie wyświetlony komunikat wskazujący, że został osiągnięty limit uprawnień, należy sprawdzić sposób nadawania uprawnień w aplikacjach klienckich lub skontaktować się z działem wsparcia IBM.