Penerapan Manajemen User dengan Autentikasi SSO Raharja.Info

Yo, share kali ini perihal User Management. Alasan kenapa perlu adanya modul ini adalah untuk pencatatan pencapaian nantinya. Hhehee.. Eh, tapi bukan itu saja, pencatatan ini juga berguna buat audit, statistik, dan penerapan peran (level management) looh :b

Mari sebelum itu, kita coba telaah gambar sederhana berikut:

Konsep ini pernah saya gunakan juga saat masih bersama RISMA 😆 Yap, sederhana memang. Tapi, karena kita menggunakan SSO (Single Sign On), kita perlu menyimpan token id_user dari Google ke dalam DB, bagian ini yang sangat membutuhkan kerja keras ekstra. Umumnya ya … umumnya, user dibuat dari create/register account. Tapi yang beda di sini, kita cukup login menggunakan SSO Rinfo lalu aplikasi akan menyimpannya otomatis untuk kita. Wah, praktis bukan… 😀

Menyambung dari pembahasan sebelumnya di sini. Cukup menambahkan Yii-user saja, set jadi trueSyaratnya, hanya tinggal memasang extension Yii-User kok.

Instalasi

  1. Unzip file ke dalam protected\modules
  2. Tambahkan listing config di main.php (protected\config): seperti di sini

Panel User

Selesai deeh … Seriusan “gampang”, kaan …? 😀

20 thoughts on “Penerapan Manajemen User dengan Autentikasi SSO Raharja.Info

  1. Kalau orang tsbt memiliki banyak level bagaimana menanganinya Dlm proses login rinfo . Karena disitu if exist saja . Bisa saja satu orang punya lebih dari satu level Klu liat gambar diatas .
    Good job ded sudah sharing yaaa .

  2. sebelum saya berikan pertanyaa mungkin kita perlu persamaan presepsi terlebih dahulu. Di Raharja ini ingin mengembangkan single manegemen user. maksudnya apa? maksudnya adalah di raharja ini akan di desain banyak aplikasi yang berdiri sendiri tapi saling terkait satu sama yang lain. Nah managemen user ini lah yang akan mengatur seluruh akses aplikasi yang terdaftar tersebut. case study -nya Misal : SiS+, OJRS+, SiS Konsultasi dll, oke lanjutkan lagi ke usernya dalam hal ini adalah pribadi raharja. Pribadi raharja ini ada beberapa jenis ( Mahasiswa, Staff, Dosen, Alumni dan pihak yg terlibat di dalam sistem ) dan sy sebut ini adalah PR. PR ini juga bisa memiliki user ganda yaitu: 1) Mahasiswa bisa menjadi Staff , 2) Mahasiswa bisa menjadi Dosen, dan 3) Staff bisa menjadi mahasiswa dan juga bisa mejadi dosen. Nah secara logika saat login di salah satu case study di atas maka sistem harus bisa mendetec si user ini menjadi apa. belum lagi prihal visitor yang hanya melihat – lihat sistem, dan yg lebih rumit lagi adalah jika di dalam sistem misalnya OJRS+ itu setiap action atau halaman memiliki user yang berbeda beda dan di kelompokan ada user untuk RPU ada user untuk KAJUR ada user untuk Sekjur dan di dalam user RPU (misalnya) memiliki 2 jenis tipe user yaitu user yg hanya bs entry dan user yang bisa edit dan acc. dari kasus ini yang ingin di kembangkan oleh raharja untuk managemen user adalah bisa mengcover tersebut menjadi global password untuk all aplikasi yang di handle oleh administrator user management. Nah Pertanyaan dari saya adalah ………? apakah sistem user ini yang menggunakan RBAC atau right atau yii-user bisa menghandle seluruhnya atau hanya satu aplikasi saja? jika bisa nanti kita lakukan uji coba ya Ded… dan ini pernah kita membahas di ruang REC priha konsep global password. TKS

    • Konsep Global Password sudah sering dibahas juga bareng2 P Ary dan P Yusup. Pembahasan obrolan di REC juga terpaparkan sangat jelas pada komen P Ary di atas. Bisa dibilang konsep ini adalah yang terbaik menurut Deddy setelah riset dengan user/right/rbac.
      Ceritanya, aplikasi akan mencatat login User untuk pertama kali login (hanya insert user ya tanpa ada kolom level apapun itu). Kemudian, dari sini kita bisa saja tentukan si user yang ada list tsb diberikan Role/Task apa saja. Dia bisa diberikan peran sebagai JurnalManager bahkan JurnalAdministrator, yang padahal dia hanyalah seorang Mahasiswa. Lain halnya jika kita tidak berikan Role/Task pada user tsb, dia hanya dapat akses publik dari AllowedListAction yang kita tuliskan. Begitu Pak @arybudiwarsito

      • pertanyaan selanjutnya Ded… coba kamu buat simulasi … bayangkan km memiliki beberapa aplikasi. jika kita menggunakan user/right/rbac pasti kita mengintall per aplikasi tersebut iya kan….. jka kita telusuri … seandainya itu aplikasi itu mengakses database yang sama , pasti menginstal user/right/rbac juga di satu database tersebut kan. Seandainya user/right/rbac di customs bisa menggunakan multiaplikasi kira-kira bisa ga ya Ded? tolong di buat uji cobanya. jika ini berhasil arti pintu gerbang SSO semakin mendekati. tks

  3. Masih ada sangkut pautnya dengan yang kemarin, bisa dibilang ini prakteknya yaa Ded. Dan sepertinya sudah berhasil ditanamnakn di dalam pessta+
    pembahasan yang Deddy lakuin disini cukup mudah dipahami ded, buat baiq yang nggak terlalu paham prihal ini juga bisa mengerti dengan sangat baik. Penasaran sih, sama satu gambar yang gak muncul di atas itu gambar apaan hehe

    But, Good Share Mas (Y)

  4. Kalau satu aplikasi gampang banget , tapi kalau antar aplikasi yang berbeda domain bisakah dihandle . Klu bisa antar aplikasi atau antar domaib aku mau lihat yah

  5. yii menyediakan dua metode authirization yaitu ACf dan RBAC . pada dasarnya sama sama access control.
    Untuk Acf adalah metode sederhana yg cocok pengaturan hak akses simple.
    Rbac pengaturan hak akses berdasarkan role pada aplikasi . Mudahnya role bisa diartikan sebagai group dari user.
    Rbac memungkinkan kita membuat hak akses secara bertingkat .
    Kalau antar aplikasi sih aku belum nyoba ded karena sisplus ojrs dan lain lain berdiri sendiri dan bukan module .dan itu inginnya diatur oleh access control satu aja . Nah konsep kamu itu bisa mengakomodasi antar aplikasi domain . ?

Leave a Reply