Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

# Contoh 1: ABAC Dasar dengan OPA dan Rego
<a name="opa-abac-examples"></a>

Bagian ini menjelaskan skenario di mana OPA digunakan untuk membuat keputusan akses tentang pengguna mana yang diizinkan mengakses informasi dalam layanan mikro Payroll fiksi. Cuplikan kode Rego disediakan untuk menunjukkan bagaimana Anda dapat menggunakan Rego untuk membuat keputusan kontrol akses. Contoh-contoh ini tidak lengkap atau eksplorasi penuh kemampuan Rego dan OPA. Untuk ikhtisar Rego yang lebih menyeluruh, kami sarankan Anda berkonsultasi dengan [dokumentasi Rego di situs web](https://www.openpolicyagent.org/docs/latest/#rego) OPA.

![ABAC Dasar dengan OPA dan Rego](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/opa-example-1.png)


## Contoh aturan OPA dasar
<a name="basic-rules"></a>

Pada diagram sebelumnya, salah satu aturan kontrol akses yang diberlakukan oleh OPA untuk layanan mikro Payroll adalah:

*Karyawan dapat membaca gaji mereka sendiri.*

Jika Bob mencoba mengakses layanan mikro Payroll untuk melihat gajinya sendiri, layanan mikro Payroll dapat mengarahkan panggilan API ke API OPA RESTful untuk membuat keputusan akses. Layanan Payroll menanyakan OPA untuk keputusan dengan masukan JSON berikut:

```
{
    "user": "bob",
    "method": "GET",
    "path": ["getSalary", "bob"]
}
```

OPA memilih kebijakan atau kebijakan berdasarkan kueri. Dalam hal ini, kebijakan berikut, yang ditulis dalam Rego, mengevaluasi input JSON.

```
default allow = false
allow = true {
    input.method == "GET"
    input.path = ["getSalary", user]
    input.user == user
}
```

Kebijakan ini menolak akses secara default. Kemudian mengevaluasi input dalam kueri dengan mengikatnya ke variabel `input` global. Operator titik digunakan dengan variabel ini untuk mengakses nilai variabel. Aturan Rego `allow` mengembalikan true jika ekspresi dalam aturan juga benar. Aturan Rego memverifikasi bahwa input `method` dalam sama dengan GET. Kemudian memverifikasi bahwa elemen pertama dalam daftar `path` adalah `getSalary` sebelum menetapkan elemen kedua dalam daftar ke variabel. `user` Terakhir, ia memeriksa bahwa jalur yang diakses adalah `/getSalary/bob` dengan memeriksa apakah `user` membuat permintaan,`input.user`, cocok dengan `user` variabel. Aturan `allow` menerapkan logika jika-maka untuk mengembalikan nilai Boolean, seperti yang ditunjukkan pada output:

```
{
    "allow": true
}
```

## Aturan sebagian menggunakan data eksternal
<a name="partial-rules"></a>

Untuk menunjukkan kemampuan OPA tambahan, Anda dapat menambahkan persyaratan ke aturan akses yang Anda terapkan. Mari kita asumsikan bahwa Anda ingin menerapkan persyaratan kontrol akses ini dalam konteks ilustrasi sebelumnya: 

*Karyawan dapat membaca gaji siapa saja yang melapor kepada mereka.*

Dalam contoh ini, OPA memiliki akses ke data eksternal yang dapat diimpor untuk membantu membuat keputusan akses:

```
"managers": {
        "bob": ["dave", "john"],
        "carol": ["alice"]
}
```

 Anda dapat menghasilkan respons JSON arbitrer dengan membuat aturan parsi di OPA, yang mengembalikan sekumpulan nilai alih-alih respons tetap. Ini adalah contoh aturan sebagian:

```
direct_report[user_ids] {
    user_ids = data.managers[input.user][_]
}
```

 Aturan ini mengembalikan satu set semua pengguna yang melaporkan ke nilai`input.user`, yang, dalam hal ini, adalah`bob`. `[_]`Konstruk dalam aturan digunakan untuk mengulangi nilai-nilai himpunan. Ini adalah output dari aturan:

```
{
    "direct_report": [
      "dave",
      "john"
    ]
}
```

Mengambil informasi ini dapat membantu menentukan apakah pengguna adalah laporan langsung dari seorang manajer. Untuk beberapa aplikasi, mengembalikan JSON dinamis lebih disukai daripada mengembalikan respons Boolean sederhana.

## Menyatukan semuanya
<a name="abac-combination"></a>

Persyaratan akses terakhir lebih kompleks daripada dua yang pertama karena menggabungkan kondisi yang ditentukan dalam kedua persyaratan:

*Karyawan dapat membaca gaji mereka sendiri dan gaji siapa saja yang melapor kepada mereka.*

Untuk memenuhi persyaratan ini, Anda dapat menggunakan kebijakan Rego ini:

```
default allow = false
 
allow = true {
    input.method == "GET"
    input.path = ["getSalary", user]
    input.user == user
}
 
allow = true {
    input.method == "GET"
    input.path = ["getSalary", user]
    managers := data.managers[input.user][_]
    contains(managers, user)
}
```

Aturan pertama dalam kebijakan memungkinkan akses untuk setiap pengguna yang mencoba melihat informasi gaji mereka sendiri, seperti yang dibahas sebelumnya. Memiliki dua aturan dengan nama yang sama,`allow`, berfungsi sebagai logika **atau** operator di Rego. Aturan kedua mengambil daftar semua laporan langsung yang terkait dengan `input.user` (dari data dalam diagram sebelumnya) dan menetapkan daftar ini ke variabel. `managers` Terakhir, aturan memeriksa apakah pengguna yang mencoba melihat gaji mereka adalah laporan langsung `input.user` dengan memverifikasi bahwa nama mereka terkandung dalam `managers` variabel.

Contoh-contoh di bagian ini sangat mendasar dan tidak memberikan eksplorasi lengkap atau menyeluruh tentang kemampuan Rego dan OPA. [Untuk informasi lebih lanjut, tinjau [dokumentasi OPA](https://www.openpolicyagent.org/docs/latest/), lihat file [OPA GitHub README](https://github.com/open-policy-agent/opa), dan bereksperimen di taman bermain Rego.](https://play.openpolicyagent.org/)