Identity-led network access

Authentication dan SSO untuk Akses Jaringan yang Lebih Sederhana.

Gunakan identity source organisasi sebagai titik awal autentikasi, teruskan konteks grup atau role ke proses access decision, dan kurangi alur login yang terpisah—dengan prerequisite serta compatibility yang tetap dapat diverifikasi.

Identity source context Group and role handoff Validated access flow
Tim IT Indonesia mengevaluasi autentikasi pengguna untuk akses jaringan
Proof required before releaseValidated authentication flow, supported identity source, login states, and error behavior.Engineering review
Satu alur evaluasi dari identity request menuju access decision.
01Request
02Verify
03Map context
04Hand off policy
Who authenticates

Mulai dari siapa yang meminta akses—bukan dari asumsi bahwa semua pengguna sama.

Employee, contractor, guest, dan account lokal memiliki konteks, durasi, serta requirement yang berbeda. Flow final harus mengikuti identity architecture dan kebijakan organisasi.

EMP

Employee

Pengguna internal yang dapat membawa konteks directory, grup, role, atau atribut yang telah ditetapkan organisasi.

Evaluasi: identity source, group structure, perubahan status pengguna, dan kebutuhan akses wired/wireless.
CTR

Contractor

Pengguna eksternal dengan kebutuhan akses terbatas, masa berlaku tertentu, atau pemisahan resource yang lebih ketat.

Evaluasi: sponsor/owner, lifecycle account, expiry, dan help path ketika akses berubah.
GST

Guest

Akses tamu perlu dibedakan dari autentikasi employee dan diarahkan ke Guest Wi-Fi journey yang memang tersedia.

Untuk self-register, token, social login, atau messaging method, gunakan halaman Guest Authentication.
LOC

Local account

Account lokal hanya boleh ditampilkan sebagai opsi apabila build produk dan skenario implementasinya benar-benar mendukung.

Jangan menjadikannya fallback default sebelum provisioning, ownership, expiry, dan audit trail tervalidasi.
Authentication flow

Dari access request menuju keputusan yang membawa konteks identitas.

Urutan ini adalah canonical solution concept. Protocol, enforcement point, timeout, session handling, dan response state harus ditetapkan pada desain teknis implementasi.

STEP 01

Access request

Pengguna memulai koneksi pada jaringan wired atau wireless melalui entry point yang telah ditentukan.

STEP 02

Identity check

Identity source yang kompatibel memverifikasi kredensial atau identitas sesuai flow yang telah diuji.

STEP 03

Profile & role context

Grup, role, atau atribut yang disetujui diterjemahkan menjadi konteks untuk kebutuhan akses.

STEP 04

Access decision

Konteks diteruskan ke policy layer atau enforcement point sesuai arsitektur dan scope implementasi.

Product truth boundary: Halaman ini tidak mengunci protocol, metode SSO, session behavior, atau enforcement model. Semua detail tersebut wajib berasal dari product documentation, compatibility review, dan hasil pengujian.
SSO value

Nilai SSO terletak pada konsistensi identity context—bukan sekadar menghilangkan satu layar login.

Outcome harus dijelaskan secara operasional dan terukur setelah flow telah divalidasi. Hindari klaim “seamless” atau “passwordless” bila pengalaman pengguna dan protocol belum dibuktikan.

01 / LOGIN

Mengurangi login yang terpisah

Menggunakan identity context organisasi dapat membantu menyederhanakan alur akses dibanding proses yang berdiri sendiri pada setiap titik jaringan.

02 / CONTEXT

Menggunakan kembali konteks pengguna

Grup, role, atau atribut yang tersedia dapat dipakai sebagai input untuk proses pemetaan akses setelah field dan mapping disetujui.

03 / OPERATIONS

Menyederhanakan pengelolaan akses

Tim dapat mengevaluasi perubahan pengguna melalui sumber identitas yang lebih terpusat daripada membuat workflow terpisah tanpa governance.

04 / REVIEW

Membuat keputusan lebih dapat ditelusuri

Identity, mapping, dan policy handoff dapat dibahas dalam satu arsitektur evaluasi yang memiliki owner, prerequisite, dan bukti implementasi.

Catatan istilah: “SSO” pada halaman ini adalah konsep solution intent. Nama protocol, pengalaman login, serta kondisi ketika pengguna tetap diminta autentikasi harus dijelaskan berdasarkan implementasi nyata.
Supported identity sources

Tampilkan hanya sumber identitas yang memiliki dokumentasi dan jalur pengujian.

Halaman solusi memberi gambaran pilihan identity source. Detail versi, port, certificate, attribute mapping, group lookup, timeout, dan troubleshooting harus dipindahkan ke halaman integrasi atau dokumentasi teknis.

Identity sourceScope halaman solusiStatus publikasi
Active DirectoryDirectory organisasi untuk identity, group, atau attribute context sesuai konfigurasi.
Tampilkan konsep dan deep-link. Versi, topology, prerequisite, mapping, serta test result berada di integration page.
Documented
LDAPDirectory access yang hanya boleh disebut setelah compatibility dan requirement teknis jelas.
Gunakan istilah LDAP secara spesifik; jangan menggeneralisasi dukungan ke seluruh directory atau vendor.
Verify version
Local identity sourceAccount atau database lokal bila memang tersedia pada build produk dan model deployment.
Jangan tampil sebagai fitur live sebelum provisioning, lifecycle, password policy, dan audit responsibility disetujui.
Conditional
Other protocols / IdPSAML, OAuth/OIDC, RADIUS, certificate, MFA, atau sumber lain.
Tidak boleh dicantumkan hanya karena umum digunakan pada industri. Tambahkan setelah dokumentasi dan test evidence tersedia.
Not claimed
Canonical boundary: Halaman ini menjelaskan “mengapa” dan “bagaimana konsepnya”. Halaman AD & LDAP Integration memiliki ownership atas detail konfigurasi, prerequisite, versi, mapping, compatibility, dan troubleshooting.
ID
Identity sourceVerified user identity from an approved source.
Input
GRP
Group or attributeSelected field that has a clear owner and mapping rule.
Context
ROL
Role mappingTranslation layer between identity context and access requirement.
Decision
POL
Policy handoffAccess direction according to validated network architecture.
Output
Role handoff

Identity tidak otomatis menjadi policy. Mapping harus dirancang, disetujui, dan diuji.

Nama grup directory sering tidak sama dengan bahasa kebijakan jaringan. Dibutuhkan translation layer yang menjelaskan field mana yang dipakai, siapa pemiliknya, bagaimana perubahan ditangani, dan apa yang terjadi ketika data tidak lengkap.

01
Pilih field yang relevanGunakan grup, role, atau custom attribute hanya setelah source dan datanya terbukti tersedia.
02
Tetapkan mapping ownerIdentity team, network team, dan business owner perlu memahami arti setiap mapping.
03
Uji perubahan lifecycleReview joiner, mover, leaver, expiry, serta perubahan grup sebelum rollout.
04
Dokumentasikan policy handoffPastikan output, enforcement point, dan exception path dapat diuji dan ditelusuri.
Guardrail: User profiling adalah konteks pengguna, bukan AI profiling atau device profiling. Pelajari ownership konsepnya pada User Profiling.
Failure & fallback

Authentication design belum lengkap sampai kondisi gagal dan jalur bantuan dipetakan.

State berikut adalah checklist evaluasi, bukan pernyataan behavior produk. Copy final harus mengikuti login state, timeout, fallback, dan support path yang benar-benar diterapkan.

401
Validate behavior

Invalid identity or credentials

Tentukan pesan yang diterima pengguna ketika identitas tidak dikenali atau verifikasi gagal, tanpa membuka informasi sensitif yang tidak diperlukan.

Visible user messageRetry or lockout ruleSupport escalation path
DIR
Validate behavior

Identity source unavailable

Bahas kondisi ketika directory, connector, atau network path tidak tersedia. Jangan mengklaim fail-open atau fail-closed sebelum arsitektur disetujui.

Timeout and retryAccess outcomeOperational alert owner
HLP
Define owner

Help and exception path

Tetapkan siapa yang menangani user issue, perubahan grup, contractor expiry, atau exception yang memang diizinkan organisasi.

Help desk responsibilityIdentity/network handoffApproval and closure evidence
Do not infer: credential lockout, retry count, session duration, emergency access, bypass account, offline authentication, dan failover behavior wajib mengikuti produk serta desain deployment nyata.
Security & data notes

Kepercayaan dibangun melalui jawaban teknis yang dapat diverifikasi.

Credential handling, encryption, certificate validation, log content, retention, dan access to administrative data tidak boleh disimpulkan dari tampilan UI atau kategori produk.

Questions to answer
CRD
Credential handlingApakah kredensial diteruskan, diproses, disimpan, atau tidak disimpan? Jawaban harus berasal dari architecture owner.
TLS
Transport and certificatesDokumentasikan jalur komunikasi, certificate requirement, validation, serta ownership renewal bila relevan.
LOG
Authentication and access logsJelaskan field yang dicatat, siapa yang dapat mengakses, tujuan penggunaan, dan periode retensi yang disetujui.
ADM
Administrative accessTetapkan role administratif, approval, perubahan konfigurasi, serta bukti audit yang benar-benar tersedia.
Evaluation FAQ

Pertanyaan yang perlu dijawab sebelum integrasi identity dimulai.

Jawaban final harus diselaraskan dengan build produk, directory environment, network architecture, serta scope implementasi yang disetujui.

Apa perbedaan halaman Authentication & SSO dengan AD & LDAP Integration?
Halaman ini menjelaskan solution concept: access request, identity check, context mapping, dan policy handoff. Halaman AD & LDAP Integration memiliki detail teknis seperti version, prerequisite, topology, field mapping, compatibility, pengujian, dan troubleshooting.
Apakah Nimbus mendukung SSO untuk semua aplikasi dan protocol?
Sumber yang tersedia belum mendukung klaim tersebut. Scope halaman ini adalah autentikasi akses jaringan. Dukungan aplikasi, protocol, identity provider, atau metode lain hanya boleh disebut setelah dokumentasi dan pengujian tersedia.
Identity source apa yang dapat digunakan?
Materi Nimbus mendokumentasikan Active Directory dan LDAP sebagai arah integrasi. Versi, prerequisite, mapping, dan compatibility harus dikonfirmasi melalui assessment serta halaman integrasi teknis.
Apakah guest menggunakan flow yang sama dengan employee?
Tidak selalu. Guest access memiliki journey, metode autentikasi, lifecycle, consent, dan support requirement yang berbeda. Gunakan halaman Guest Wi-Fi Authentication untuk mengevaluasi self-register, token, social login, atau messaging method yang tersedia.
Bagaimana grup atau role diterjemahkan menjadi akses jaringan?
Identity field perlu dipilih, dipetakan ke role yang memiliki arti operasional, lalu diteruskan ke policy layer sesuai arsitektur. Mapping, enforcement point, exception, dan perubahan lifecycle harus dirancang serta diuji bersama tim identity dan network.
Apa yang terjadi ketika directory tidak tersedia?
Behavior tersebut belum boleh diasumsikan. Timeout, retry, failover, fail-open/fail-closed, local fallback, pesan pengguna, serta escalation path harus dikonfirmasi dari desain implementasi dan bukti pengujian.
Apakah credential pengguna disimpan oleh Nimbus?
Sumber yang tersedia belum memberi detail yang cukup untuk membuat klaim. Credential handling, transport, certificate, log content, retention, dan administrative access perlu ditetapkan oleh product owner dan engineer sebelum dipublikasikan.
Apa yang perlu disiapkan untuk technical assessment?
Siapkan gambaran identity source, versi dan topology directory, kelompok pengguna, field/grup yang relevan, jaringan wired/wireless, controller atau enforcement point, access policy awal, failure scenario, support owner, serta target POC.
Identity dan network engineer Indonesia mendiskusikan desain autentikasi akses jaringan
Identity assessment

Bawa identity architecture Anda ke percakapan teknis yang terarah.

Tim Nimbus dapat membantu memetakan access request, identity source, grup atau role, policy handoff, failure state, dan kebutuhan POC—tanpa mengunci klaim sebelum environment Anda ditinjau.

Identity source reviewGroup-to-role mappingAuthentication state checklistPOC discussion