Product-apim: Mendukung Otentikasi Dasar untuk Pelanggan

APIM 3.0.0 yang baru dirilis mendukung Auth Dasar. Saat ini kami menggunakannya di lingkungan kami.

Ya untuk titik akhir backend. Untuk Api saya tidak dapat menemukan opsi.

Penerbit API -> Konfigurasi Waktu Proses -> Keamanan Tingkat Aplikasi

@Tomas-Mrazek benar, Sekarang kami juga mendukung Otentikasi Dasar untuk klien API. Anda dapat mengaktifkan opsi Basic bawah keamanan tingkat aplikasi seperti yang ditunjukkan di atas. Ini akan memungkinkan konsumen API untuk memanggil API ini menggunakan kombinasi kata sandi nama pengguna mereka.

Oke, sepertinya saya mencari di tempat yang sama. Baru saja diuji dan berfungsi.

Ini membawa lebih banyak pertanyaan.

Bagaimana cara kerja langganan dengan autentikasi dasar? Sepertinya setiap pengguna dapat memanggil Api apa pun, terlepas dari langganan? Apakah ada cara untuk "menetapkan" pengguna ke aplikasi tertentu sehingga mereka hanya dapat memanggil API ke aplikasi mana yang berlangganan?

Jika Prod dan Sandbox berbagi Gateway yang sama, bagaimana cara menentukan Gateway mana yang dipanggil saat melakukan autentikasi dasar?

Kedua pertanyaan ini tidak memerlukan jawaban jika kita menggunakan kunci aplikasi dan rahasia aplikasi alih-alih nama pengguna dan kata sandi dalam auth dasar.

Mungkin saya melewatkan sesuatu, jadi akan lebih baik jika Anda bisa mengarahkan saya ke dokumentasi.

Bagaimana cara kerja langganan dengan autentikasi dasar? Sepertinya setiap pengguna dapat memanggil Api apa pun, terlepas dari langganan? Apakah ada cara untuk "menetapkan" pengguna ke aplikasi tertentu sehingga mereka hanya dapat memanggil API ke aplikasi mana yang berlangganan?

Tidak, itu harus bekerja sama dengan token oauth2. Hanya pengguna yang berlangganan yang dapat memanggil API, tidak masalah apakah melalui token atau Auth Dasar.

Anda tidak dapat menetapkan pengguna ke aplikasi, karena cara kerjanya berlawanan - aplikasi milik pengguna. Jika Anda menginginkan kontrol yang lebih halus, buat peran di /carbon console dan tetapkan ke pengguna. Di penerbit API, buka pengaturan API, ubah visibilitas di devportal ke peran tertentu. Kemudian buat cakupan dengan peran khusus untuk setiap sumber daya, tetapkan cakupan ini ke sumber daya, aktifkan keamanan. Pengguna yang berlangganan lebih dari yang dapat membatalkan API, tetapi tanpa Anda menetapkan peran kepada pengguna, mereka tidak dapat memanggil sumber daya apa pun yang dilindungi.

Jika Prod dan Sandbox berbagi Gateway yang sama, bagaimana cara menentukan Gateway mana yang dipanggil saat melakukan autentikasi dasar?

Pertanyaan bagus. Saya tidak tahu jawabannya.

Omong-omong, ini tidak akan berfungsi dengan kunci dan rahasia konsumen. Titik akhir ditentukan selama pembuatan /token AFAIK.

Hai @Tomas-Mrazek dan @tmkasun , ini persis masalah saya dengan otentikasi Dasar sekarang. Biarkan saya mencoba meringkas pemikiran saya tentang otentikasi:

OAuth2 - kami berlangganan Aplikasi ke Api. Berdasarkan kunci dan rahasianya, kami mengetahui Aplikasi dan Lingkungannya. Jadi, untuk mengizinkan Aplikasi menggunakan Api, yang perlu kita lakukan hanyalah berlangganan. Kemudian, setiap pengguna dapat memanggil Api itu karena dia tahu kunci dan rahasianya.

Kunci Api Statis - di sini kita tahu Kuncinya, dan itu memberikan informasi yang cukup untuk mengetahui Aplikasi mana yang memanggil Api, dan lingkungan mana yang digunakannya. Konsep Aplikasi berlangganan Api untuk menggunakannya masih berlaku. Kami hanya perlu berlangganan Aplikasi ke Api.

Otentikasi dasar seperti sekarang - Saya akan menyebutnya "auth dasar berbasis pengguna". Itu benar-benar meninggalkan konsep Aplikasi dan langganan, dan memerlukan penggunaan konsep yang berbeda (izin berbasis pengguna) dan alat yang berbeda seperti menggunakan admin Karbon alih-alih Penerbit atau Toko/DevPortal. Dan itu tidak dapat membedakan antara produksi dan lingkungan kotak pasir ketika satu gerbang digunakan untuk keduanya. Ini juga memberikan tingkat kerumitan tambahan untuk diatur dan dikelola. Sekarang tidak cukup dengan melihat daftar Aplikasi yang berlangganan, kita juga harus pergi ke admin karbon dan melihat pengguna dan izinnya. Dan jika saya ingin menilai batas satu Aplikasi tertentu untuk Api, atau memiliki tingkat langganan yang berbeda, saya tidak dapat melakukannya untuk pengguna.

Apa yang saya lihat sebagai cara yang "benar" untuk mendukung Otentikasi Dasar adalah sebagai berikut:

Otentikasi Dasar Tingkat Aplikasi - Kami melepaskan pengguna dari konsep (seperti dengan kunci statis) dan menggunakan autentikasi aplikasi sebagai gantinya. Aplikasi masih perlu berlangganan Api. Kunci Konsumen dan Rahasia konsumen digunakan sebagai kredensial otentikasi dasar. Dengan begitu kami mempertahankan konsep Berlangganan Aplikasi / Api, dapat terus menggunakan alat yang sama seperti untuk yang lainnya (penerbit / devPortal, tidak perlu Admin Karbon), dan kami tahu Aplikasi mana yang menggunakan Api mana dan lingkungan mana berdasarkan kuncinya.

Bagaimana menuju ke sana?

Ada dua pilihan. Ubah implementasi Dasar saat ini ke yang diusulkan di atas, atau terapkan yang baru yang disebut "Otentikasi Dasar Aplikasi".
Ada juga opsi ketiga, untuk mendukung pengguna/pass dan kunci/rahasia dalam autentikasi dasar yang ada, tapi itu yang paling kotor.

Implementasi Auth dasar tidak cukup. Misalnya Anda dapat membatasi visibilitas API pada devportal berdasarkan peran -> yang perlu dibuat dan dikaitkan dengan pengguna melalui konsol Carbon.

Hai @Tomas-Mrazek dan @markokocic
Terima kasih atas saran Anda, Silakan temukan jawaban saya sebaris.

Bagaimana cara kerja langganan dengan autentikasi dasar? Sepertinya setiap pengguna dapat memanggil Api apa pun, terlepas dari langganan? Apakah ada cara untuk "menetapkan" pengguna ke aplikasi tertentu sehingga mereka hanya dapat memanggil API ke aplikasi mana yang berlangganan?

Dukungan autentikasi dasar untuk permintaan klien tidak memerlukan langganan. Jika pembuat API telah mengaktifkan dukungan Otentikasi Dasar untuk API tertentu, API tersebut dapat dipanggil tanpa berlangganan API tersebut (Dengan aplikasi).
dan @markokocic ya, cara kerja langganan , An Application subscribed to an API .

Selanjutnya dengan Baisc auth:
Anda masih mendapatkan:

• Tingkat sumber daya atau pelambatan tingkat API
• Validasi cakupan sumber daya

Anda tidak akan mendapatkan:

• Pembatasan tingkat langganan
• Diferensiasi lingkungan Produksi & Sandbox

Jika Prod dan Sandbox berbagi Gateway yang sama, bagaimana cara menentukan Gateway mana yang dipanggil saat melakukan autentikasi dasar?

Ya, kami tidak dapat membedakan lingkungan dengan nama pengguna dan kata sandi, Oleh karena itu saat menggunakan auth dasar, Anda tidak akan memiliki opsi untuk memilih lingkungan, Titik akhir produksi akan digunakan.

@Tomas-Mrazek

Titik akhir ditentukan selama pembuatan /token AFAIK.

Tidak, Titik Akhir (Prod & Sandbox) ditentukan oleh pembuat API saat membuat API, konsumen API dapat memberikan URL panggilan balik untuk aplikasi jika mereka ingin menggunakan jenis pemberian berbasis arahan ulang (yaitu implisit)

@markokocic tentang

Otentikasi Dasar tingkat Aplikasi

Hal ini dimungkinkan dengan implementasi saat ini juga. Anda dapat menggunakan jenis pemberian kredensial klien untuk mendapatkan pasangan token atas nama pemilik aplikasi.

Otentikasi Dasar tingkat Aplikasi

Hal ini dimungkinkan dengan implementasi saat ini juga. Anda dapat menggunakan jenis pemberian kredensial klien untuk mendapatkan pasangan token atas nama pemilik aplikasi.

@tmkasun
Ya, otentikasi dasar dapat digunakan untuk menghasilkan token menggunakan kredensial klien. Anda menggunakan sesuatu seperti ini:

curl -k -X POST https://localhost:8243/token -d "grant_type=client_credentials" -H "Authorization: Basic Base64(consumer-key:consumer-secret)"

Namun, untuk menggunakan API, konsumen Anda tetap harus dapat:

• hasilkan token menggunakan metode di atas
• atur sebagai header http "Otorisasi" dengan Pembawa dan Token untuk permintaan API yang sebenarnya
• akhirnya mengurus kedaluwarsa dan penyegaran token

Tidak apa-apa jika programmer memprogram konsumen Anda, atau Anda memiliki vendor yang dapat melakukannya. Seperti yang dijelaskan, masalahnya ada pada banyak klien perusahaan lawas yang tidak dapat disesuaikan. Misalnya di SAP jika Anda ingin menggunakan layanan eksternal, satu-satunya hal yang dapat Anda atur adalah URL, dan secara opsional nama pengguna dan kata sandi untuk otentikasi dasar. Di sana Anda tidak memiliki kemampuan untuk mengambil token atau mengatur header khusus.

Apa yang saya jelaskan sebagai Otentikasi Dasar tingkat Aplikasi di atas sebenarnya adalah kemampuan untuk melewati langkah pembuatan token, dan langsung menggunakan Otentikasi Dasar berdasarkan kredensial klien untuk memanggil API.

Sesuatu seperti:

curl -k -X POST https://localhost:8243/my/nice/Api/doSomething -H "Authorization: Basic Base64(consumer-key:consumer-secret)"

Ini akan memungkinkan saya untuk tetap menggunakan model langganan Aplikasi ke API yang sama dengan cara yang seragam, tanpa perlu membuat, menyiapkan, dan mengelola pengguna.

Sebagai manfaat lain, karena standar otentikasi Dasar menyediakan kemampuan untuk menyertakan header otorisasi sebagai bagian dari URL, kami bahkan dapat mendukung Konsumen lama dengan sesuatu seperti ini:

curl -k -X POST https://consumer-key:consumer-secret<strong i="25">@localhost</strong>:8243/my/nice/Api/doSomething

EDIT: Sekarang saya memikirkannya, mungkin nama yang lebih jelas adalah Otentikasi Dasar berbasis Klien-Kredensial untuk API.