Bastillion

أداة عصرية قائمة على المتصفح لإدارة اتصالات SSH ومفاتيح SSH.

يمنحك Bastillion طريقة نظيفة قائمة على المتصفح لإدارة وصول SSH عبر جميع أنظمتك — مثل مضيف حصن (bastion host) مع لوحة تحكم سهلة الاستخدام. يقوم بأمرين:

طرفية SSH قائمة على الويب — بمجرد تسجيل مضيف، يمكن للمستخدمين المصرح لهم فتح جلسة طرفية حية واحدة أو أكثر إليه مباشرة من المتصفح، مع إمكانية بث الأوامر في وقت واحد عبر جميع الجلسات المفتوحة (فكر في الأجزاء المتزامنة في tmux، ولكن لأسطول من المضيفين البعيدين بدلاً من الأجزاء المحلية).
إدارة مفاتيح SSH — يحتفظ Bastillion بزوج مفاتيح SSH الخاص به ويدفع/يدوّر المفاتيح العامة عبر المضيفين الذين تسجلهم، بحيث لا يحتاج المستخدمون الأفراد أبدًا إلى الاحتفاظ أو إدارة مفاتيح طويلة الأمد لتلك الأنظمة بأنفسهم.

تسجيل الدخول مع المصادقة الثنائية (Authy أو Google Authenticator)
إدارة وتوزيع المفاتيح العامة SSH، وتعطيلها/تدويرها مركزيًا
إطلاق أغلفة ويب متعددة الجلسات آمنة ومشاركة الأوامر عبر الجلسات
تسجيل كل جلسة وإعادة تشغيلها عند الطلب — أدلة جاهزة للتدقيق لأي إطار امتثال
تجميع الأنظمة في ملفات تعريف (Profiles) والتحكم بدقة في من يمكنه الوصول إلى ماذا
حفظ وإعادة تشغيل البرامج النصية المركبة (Composite Scripts) عبر أسطول كامل في وقت واحد
تكديس TLS/SSL فوق SSH لحماية إضافية

طرفيات متعددة تبث نفس الأمر إلى ثلاثة مضيفين في وقت واحد

_{ثلاث جلسات SSH حقيقية ومستقلة — أمر واحد، يُكتب مرة واحدة، ويُشغَّل في كل مكان.}

كيف يعمل

يجلس Bastillion بين مستخدميك والأنظمة التي يحتاجون إلى الوصول إليها، ويعمل كطرف ثالث موثوق به بدلاً من كونه مجرد خزنة كلمات مرور. إليك دورة الحياة الكاملة، من البداية إلى النهاية.

1. يولّد Bastillion زوج مفاتيح SSH الخاص به

عند أول تشغيل، وقبل أي شيء آخر، يولّد Bastillion زوج مفاتيح Ed25519 لنفسه — هذا هو المفتاح الوحيد الذي يُدفع إلى مضيفيك على الإطلاق. يظهر في مخرجات وحدة التحكم ويكون مرئيًا دائمًا تحت الإعدادات (Settings).

2. تسجيل نظام

يضيف مسؤول مضيفًا تحت إدارة ← الأنظمة (Manage → Systems) (المستخدم، المضيف، المنفذ، ومسار ملف authorized_keys لذلك المضيف). يصادق Bastillion مرة واحدة بكلمة مرور أو عبارة مرور تقدمها، ثم يدفع مفتاحه العام إلى ملف authorized_keys الخاص بذلك المضيف. منذ ذلك الحين يتصل باستخدام ذلك المفتاح — لا كلمات مرور مخزنة، أبدًا. تتغير الحالة إلى نجاح (Success) في اللحظة التي يكون فيها المفتاح في مكانه.

إدارة الأنظمة — ثلاثة مضيفين مسجلين، جميعهم بحالة نجاح

3. تجميع الأنظمة في ملفات تعريف، وتعيين المستخدمين

تُجمَّع الأنظمة في ملفات تعريف (Profiles) مسماة — فكر في "الإنتاج (Production)"، "المرحلة التجريبية (Staging)"، "طبقة قواعد البيانات (Database Tier)". ثم يتم ربط المستخدمين بملفات التعريف تحت إدارة ← المستخدمين (Manage → Users)، وهو الشيء الوحيد الذي يتحكم في من يمكنه الوصول إلى ماذا. قم بإلغاء تعيين ملف تعريف ويختفي ذلك الوصول فورًا، دون الحاجة إلى تدوير المفاتيح.

تعيين ثلاثة أنظمة لملف تعريف الإنتاج

4. فتح الطرفيات — والبث إلى جميعها في وقت واحد

يفتح المستخدمون المعينون الغلاف الآمن ← الطرفيات (Secure Shell → Terminals)، ويختارون نظامًا واحدًا أو أكثر، ويحصلون على طرفيات حية قابلة لتغيير الحجم قائمة على xterm في المتصفح، جنبًا إلى جنب. اكتب مرة واحدة، ويصل الأمر إلى كل طرفية محددة كنشطة — نفس ضغطة المفتاح، نفس الأمر، نفس شكل المخرجات، عبر عدد المضيفين الذين حددتهم.

أمر فحص صحي يُبث إلى ثلاث طرفيات في وقت واحد، بنفس شكل المخرجات عبر الثلاثة

5. تدوير المفاتيح أو إلغاؤها مركزيًا

نظرًا لأن كل مضيف يثق في نفس مفتاح التطبيق (وليس مفتاحًا واحدًا لكل مستخدم)، فإن تعطيله مرة واحدة تحت إدارة مفاتيح SSH (Manage SSH Keys) يلغي الوصول في كل مكان فورًا — دون الحاجة إلى لمس الأنظمة المستهدفة يدويًا، ودون البحث عن أي خادم يحمل أي مفتاح قديم.

إدارة مفاتيح SSH مع ملف التعريف والبصمة وتاريخ الإنشاء وإجراءات الحذف

6. كل جلسة مسجلة — التدقيق وإعادة التشغيل

كل ما يُكتب وكل بايت يُعاد في تلك الطرفيات يُسجل تلقائيًا. يفتح المديرون جلسات التدقيق (Audit Sessions)، ويصفون حسب المستخدم أو النظام، ويعيدون تشغيل أي جلسة — جنبًا إلى جنب للجلسات التي امتدت عبر مضيفين متعددين، مع مرشح نصي للانتقال مباشرة إلى الأسطر المهمة. تتدفق المخرجات إلى الصفحة أثناء تحميلها، بحيث حتى الجلسة التي أفرغت مئات الميغابايت من السجلات تُعاد تشغيلها دون عناء.

إذا كنت بحاجة إلى إظهار مدقق حسابات من نفّذ ماذا، وأين، ومتى — فهذا هو الدليل، ملتقطًا خارج الصندوق. تقريبًا كل إطار امتثال لديه متطلب مسار تدقيق وصول مميز في مكان ما (PCI DSS، HIPAA، SOC 2، ISO 27001 — اختر ما يناسبك)، وهذا يحقق ذلك المربع دون منتج PAM تجاري. تُحفظ الجلسات لمدة 90 يومًا افتراضيًا (deleteAuditLogAfter)، ويمكن إيقاف التسجيل باستخدام ENABLE_INTERNAL_AUDIT=false — انظر التدقيق.

جلسات التدقيق مدرجة مع مرشحات المستخدم والنظام

🚀 ما الجديد

SAML 2.0 SSO — تسجيل الدخول عبر مزود هوية مؤسسي (Entra ID، Okta، ADFS، وغيرها) — انظر الإعدادات
الترخيص — مجاني حتى 8 أنظمة، مع مستويات مدفوعة متاحة على loophole.company/pricing.html (انظر الترخيص أدناه)
تدقيق الجلسات وإعادة تشغيلها، مفعّل افتراضيًا — كل جلسة طرفية تُسجل ويمكن إعادة تشغيلها تحت جلسات التدقيق (Audit Sessions)، وتُبث إلى المتصفح بحيث حتى الجلسات الضخمة تُحمَّل فورًا
يعمل كملف jar مستقل (java -jar) مع HTTPS خارج الصندوق — انظر التنزيل والتشغيل
تمت الترقية إلى Java 21 وJetty 12 وJakarta EE 10
دعم كامل لمفاتيح Ed25519 (الافتراضي) وEd448 SSH
أداة ترحيل v4 → v5 لنقل المستخدمين والأنظمة والمفاتيح وسجلات التدقيق من مثيل موجود — انظر tools/migrate
محصّن بمرشح CSRF وترويسات أمان على مستوى التطبيق

الترخيص

يعمل Bastillion بدون ترخيص حتى 8 أنظمة مسجلة — وهو ما يكفي لتجربته فعليًا قبل الشراء. يرفع الترخيص هذا الحد الأقصى.

اشترِ ترخيصًا على loophole.company/pricing.html (مبتدئ/فريق/أعمال — مسعّر حسب عدد الأنظمة). يعيد الدفع التوجيه ويقوم بتنزيل ملف .lic تلقائيًا.
افتح ملف .lic وانسخ محتوياته (سطر واحد).
عيّنه عبر متغير البيئة LICENSE_KEY: ```bash export LICENSE_KEY=

أو الصقه في licenseKey في BastillionConfig.properties بدلاً من ذلك — متغير البيئة له الأولوية إذا تم تعيين كلاهما. 4. أعد تشغيل Bastillion. تعرض الإعدادات المرخَّص له، وسقف النظام، وتاريخ الانتهاء، مع تحذير يبدأ قبل 90 يومًا من انتهاء الصلاحية.

التراخيص سنوية ولا تتجدد تلقائيًا — لا يتم الاحتفاظ ببطاقة دفع مسجلة. اشترِ مرة أخرى من نفس صفحة التسعير عندما يصلك تحذير الانتهاء.

خيارات التثبيت

مجاني: https://github.com/bastillion-io/Bastillion/releases

المتطلبات الأساسية

Java 21 (OpenJDK)```bash

apt-get install openjdk-21-jdk

### المصادق (للتحقق بخطوتين)

| التطبيق | أندرويد | آي أو إس |
|--------------|----------|-----|
| **Authy** | [Google Play](https://play.google.com/store/apps/details?id=com.authy.authy) | [iTunes](https://itunes.apple.com/us/app/authy/id494168017) |
| **Google Authenticator** | [Google Play](https://play.google.com/store/apps/details?id=com.google.android.apps.authenticator2) | [iTunes](https://itunes.apple.com/us/app/google-authenticator/id388497605) |

---

## التنزيل والتشغيل

قم بتنزيل أحدث ملف jar من [Releases](https://github.com/bastillion-io/Bastillion/releases):```bash
java -jar bastillion-<version>.jar

الوصول عبر المتصفح: https://<server-ip>:8443 — راجع TLS / HTTPS أدناه للحصول على شهادة التوقيع الذاتي التي يولّدها Bastillion عند أول تشغيل.

بيانات الاعتماد الافتراضية:``` username: admin password: changeme

يعمل في المقدمة؛ أوقفه باستخدام Ctrl+C. للتشغيل في الخلفية أو كخدمة خلفية (daemon)، استخدم ما تستخدمه منصتك عادةً لعملية Java طويلة التشغيل — مثل `nohup java -jar ... &`، أو وحدة systemd، أو حاوية، وما إلى ذلك.

---

## البناء من المصدر

ثبّت Maven 3+:```bash
apt-get install maven

قم بالبناء والتشغيل (يحزم ملف jar ذاتي الاحتواء مع خادم Jetty مدمج — انظر io.bastillion.Main — ويقوم بتشغيله):```bash mvn package java -jar target/bastillion-5.0.0-SNAPSHOT.jar

أو للتطوير المحلي دون إعادة التغليف عند كل تغيير:```bash
mvn compile exec:java

يستمع على https://localhost:8443 افتراضيًا، كما هو الحال مع الإصدار الذي تم تنزيله أعلاه — راجع نظام TLS / HTTPS أدناه لمعرفة كيفية إعداد تلك الشهادة وكيفية استخدام شهادتك الخاصة بدلاً منها.

نظام TLS / HTTPS

يقوم Bastillion بإنشاء شهادته الذاتية التوقيع الخاصة به عند أول تشغيل ويخدم HTTPS — لا حاجة لتكوين أي شيء. ستعرض المتصفحات تحذيرًا مرة واحدة (إنها ذاتية التوقيع، وليست صادرة عن جهة تصديق CA)؛ تجاوزها بالنقر، تمامًا كما تفعل مع أي جهاز مستضاف ذاتيًا آخر. تبقى الشهادة وكلمة المرور الخاصة بها محفوظة عبر عمليات إعادة التشغيل (keystore/bastillion.p12 ضمن CONFIG_DIR، وكلمة المرور مخزنة بنفس الطريقة المشفرة مثل كلمة مرور قاعدة البيانات).

استخدم شهادتك الموقعة من جهة تصديق CA بدلاً من الشهادة الذاتية التوقيع الافتراضية — على سبيل المثال شهادة مجانية من Let's Encrypt:

أصدر الشهادة باستخدام certbot (يتطلب اسم DNS حقيقي يشير إلى هذا المضيف، ومنفذ 80 قابل للوصول لتحدي HTTP-01): ```bash sudo certbot certonly --standalone -d bastillion.example.com

يكتب هذا الأمر fullchain.pem و privkey.pem إلى /etc/letsencrypt/live/bastillion.example.com/.

قم بتحويل زوج الشهادة/المفتاح إلى صيغة PKCS12، وهي صيغة مخزن المفاتيح التي يتوقعها Bastillion: ```bash openssl pkcs12 -export
-in /etc/letsencrypt/live/bastillion.example.com/fullchain.pem
-inkey /etc/letsencrypt/live/bastillion.example.com/privkey.pem
-out bastillion.p12 -name bastillion -passout pass:changeit
وجّه Bastillion إليه وأعد تشغيله: ```bash export KEYSTORE_PATH=/path/to/bastillion.p12 export KEYSTORE_PASSWORD=changeit

ستثق المتصفحات الآن بالاتصال دون أي تحذير. تنتهي صلاحية شهادات Let's Encrypt كل 90 يومًا — certbot renew متبوعًا بإعادة تنفيذ الخطوات 2–3 (وإعادة تشغيل) يُبقيها محدثة؛ ويمكن لـ certbot renew --deploy-hook أتمتة ذلك.

خلف وكيل عكسي أو موازن تحميل ينهي بالفعل TLS (nginx، Cloud Run، إلخ.) — عطّل HTTPS الخاص بـ Bastillion واتركه يخدم HTTP عادي بدلاً من ذلك:```bash export TLS_ENABLED=false

المنفذ الافتراضي هو 8080 في هذا الوضع؛ اضبط `PORT` لتغييره.

---

## الإعدادات

يمكن ضبط كل إعداد أدناه كـ **متغير بيئة** — خذ اسم الخاصية وأدخل
شرطة سفلية قبل كل حرف كبير، ثم حوّله إلى أحرف كبيرة: `licenseKey` ←
`LICENSE_KEY`، `dbUser` ← `DB_USER`، `sshKeyType` ← `SSH_KEY_TYPE`. هذه هي الطريقة الموصى
بها لتهيئة Bastillion، خاصة في الحاويات — لا حاجة لملف يتم تركيبه أو تضمينه.

لا يزال `BastillionConfig.properties` يعمل كخيار احتياطي (متغيرات البيئة تفوز دائمًا إذا تم ضبط كلاهما)،
وهو المكان الذي يتم فيه حفظ أي قيمة يولّدها Bastillion لك عند أول تشغيل — مثل كلمة مرور
قاعدة البيانات العشوائية. راجع `src/main/resources/BastillionConfig.properties` للحصول على
القائمة الكاملة للإعدادات وقيمها الافتراضية.

**توحيد كل شيء تحت دليل واحد** (مثل نقطة تركيب وحدة تخزين Docker واحدة):
`CONFIG_DIR` هو الإعداد الوحيد الذي تحتاجه. كل ما يستمر Bastillion في حفظه —
`BastillionConfig.properties`، مخزن مفاتيح TLS الموقّع ذاتيًا (`keystore/bastillion.p12`)،
قاعدة بيانات H2 وزوج مفاتيح مضيف SSH (كلاهما تحت `keydb/`)، و`bastillion.jceks` — يقع
تحته افتراضيًا، لذا فإن توجيه `CONFIG_DIR` إلى مكان واحد ينقل كل ذلك:```bash
export CONFIG_DIR=/data/bastillion/

KEYSTORE_PATH وDB_CONNECTION_URL لا يزالان موجودين لتوجيه أحدهما فقط إلى موقع مختلف بمفرده (شهادة حقيقية، قاعدة بيانات بعيدة) — انظر TLS / HTTPS و قسم "إعدادات قاعدة البيانات" أدناه — لكن لا يلزم أي منهما فقط لتوحيد كل شيء في CONFIG_DIR.

CONFIG_DIR نفسه يضع افتراضيًا على ./config نسبةً إلى دليل العمل. هل تقوم بترقية مثيل حالي لم يضبطه مطلقًا؟ الإصدارات الأقدم كانت تخزن الحالة مباشرة في دليل العمل بدلاً من ./config — يكتشف Bastillion ذلك عند أول تشغيل مع هذا الإصدار وينقله إلى ./config (أو إلى CONFIG_DIR، إذا قمت الآن بتعيين واحد) تلقائيًا.

إدارة مفاتيح SSH

```bash # Disable key management (append instead of overwrite) export KEY_MANAGEMENT_ENABLED=false

authorized_keys refresh interval in minutes (no refresh for <=0)

export AUTH_KEYS_REFRESH_INTERVAL=120

Force user key generation and strong passphrases

export FORCE_USER_KEY_GENERATION=false

</details>

<details>
<summary><strong>زوج مفاتيح SSH مخصص</strong></summary>

بشكل افتراضي، يولّد Bastillion زوج مفاتيح Ed25519 خاصًا به عند أول تشغيل. لاستخدام مفتاحك الخاص
بدلاً من ذلك، أسهل طريقة هي عبر الواجهة: **الإعدادات ← استبدال مفتاح SSH الخاص بالتطبيق**
(حسابات المدير فقط) — الصق مفتاحًا خاصًا ومفتاحًا عامًا وعبارة مرور إذا كانت موجودة،
وسيتم تطبيق ذلك فورًا دون الحاجة إلى إعادة تشغيل.

⚠️ هذا يستبدل المفتاح *الوحيد* الذي تثق به كل الأنظمة المسجلة. وهو مخصص كخطوة لمرة واحدة
عند إعداد Bastillion لأول مرة، **قبل** تسجيل أي أنظمة — إذا كان لديك بالفعل
أنظمة مسجلة، سيفقد Bastillion وصول SSH إلى جميعها في اللحظة التي تستبدل فيها
المفتاح، ما لم يكن هذا المفتاح بالضبط موجودًا بالفعل في `authorized_keys` على كل واحد منها
أولًا. تتطلب صفحة الإعدادات مربع تأكيد إضافيًا بمجرد وجود أنظمة مسجلة لديك،
وذلك تحديدًا بسبب هذا الأمر.

**هل لديك أنظمة مسجلة بالفعل وتحتاج إلى تدوير المفتاح على أي حال؟** قم بمرحلة ما قبل التجهيز للمفتاح الجديد
عبر Bastillion نفسه بدلاً من تحرير `authorized_keys` يدويًا في كل مكان:

1. اضبط `FORCE_USER_KEY_GENERATION=false` بحيث يتيح لك **إدارة مفاتيح SSH ← إضافة مفتاح SSH** لصق
   مفتاح عام موجود بدلاً من توليد مفتاح جديد فقط.
2. أضف المفتاح الجديد هناك مقابل ملف تعريف يغطي جميع أنظمتك، وتأكد (ضمن
   إدارة مفاتيح SSH، أو حالة كل نظام) أنه وصل فعليًا إلى كل مكان — ضع
   `AUTH_KEYS_REFRESH_INTERVAL` في الاعتبار، لأنه ما يدفعه للانتشار.
3. فقط بمجرد التأكد من وجوده على كل نظام، استبدل مفتاح التطبيق في الإعدادات.
4. أعد ضبط `FORCE_USER_KEY_GENERATION` إلى قيمته السابقة، ثم بمجرد تأكيد
   أن مفتاح التطبيق الجديد قد انتشر إلى كل نظام (مرة أخرى، انتبه إلى
   `AUTH_KEYS_REFRESH_INTERVAL`)، أزل المفتاح الذي أضفته في الخطوة 2 من إدارة مفاتيح SSH —
   فقد كان مرحليًا هناك فقط لتهيئة `authorized_keys` مسبقًا وليس مطلوبًا للمضي قدمًا.

بالنسبة للإعدادات النصية/بدون واجهة رسومية، يمكن القيام بنفس الشيء عبر متغيرات البيئة
وإعادة تشغيل بدلاً من ذلك:```bash
# Regenerate and import SSH keys
export RESET_APPLICATION_SSH_KEY=true

# Private key
export PRIVATE_KEY=/Users/you/.ssh/id_rsa

# Public key
export PUBLIC_KEY=/Users/you/.ssh/id_rsa.pub

# Passphrase (leave blank if none)
export DEFAULT_SSH_PASSPHRASE=myPa$$w0rd

بمجرد التسجيل، يمكنك تجاهل هذه — زوج المفاتيح مخزّن بالفعل في قاعدة البيانات.

SSH_KEY_TYPE (rsa, ecdsa, ed25519, أو ed448) يهم فقط عندما يقوم Bastillion بتوليد مفتاح جديد، وليس عند استيراد واحد — نوع المفتاح المستورد يُقرأ من المفتاح نفسه:```bash

SSH key type ('rsa', 'ecdsa', 'ed25519', or 'ed448')

Supported options:

rsa - Classic, widely compatible (configurable length, default 4096)

ecdsa - Faster, smaller keys (P-256/384/521 curves)

ed25519 - Default and recommended (≈ RSA-4096, secure and fast)

ed448 - Extra-strong (≈ RSA-8192, slower and less supported)

export SSH_KEY_TYPE=ed25519

</details>

<details>
<summary><strong>إعدادات قاعدة البيانات</strong></summary>

مثال H2 المضمّن:```bash
export DB_USER=bastillion
export DB_PASSWORD=p@$$w0rd!!
export DB_DRIVER=org.h2.Driver
export DB_CONNECTION_URL=jdbc:h2:file:keydb/bastillion;CIPHER=AES;

مثال H2 عن بُعد:```bash export DB_CONNECTION_URL=jdbc:h2:tcp://:/~/bastillion;CIPHER=AES;

</details>

<details>
<summary><strong>المصادقة الخارجية (LDAP / JAAS)</strong></summary>

قم بالمصادقة مقابل خادم LDAP/Active Directory موجود بدلاً من كلمات المرور المحلية (أو إلى جانبها).
قم بتمكينها:```bash
export JAAS_MODULE=ldap-ol

قم بتكوين jaas.conf:``` ldap-ol { com.sun.security.auth.module.LdapLoginModule SUFFICIENT userProvider="ldap://hostname:389/ou=example,dc=bastillion,dc=com" userFilter="(&(uid={USERNAME})(objectClass=inetOrgPerson))" authzIdentity="{cn}" useSSL=false debug=false; };

لتعيين أدوار LDAP إلى ملفات تعريف Bastillion:```
ldap-ol-with-roles {
    org.eclipse.jetty.security.jaas.spi.LdapLoginModule required
    debug="false"
    useLdaps="false"
    contextFactory="com.sun.jndi.ldap.LdapCtxFactory"
    hostname="<SERVER>"
    port="389"
    bindDn="<BIND-DN>"
    bindPassword="<BIND-DN PASSWORD>"
    authenticationMethod="simple"
    forceBindingLogin="true"
    userBaseDn="ou=users,dc=bastillion,dc=com"
    userRdnAttribute="uid"
    userIdAttribute="uid"
    userPasswordAttribute="userPassword"
    userObjectClass="inetOrgPerson"
    roleBaseDn="ou=groups,dc=bastillion,dc=com"
    roleNameAttribute="cn"
    roleMemberAttribute="member"
    roleObjectClass="groupOfNames";
};

يتم إضافة المسؤولين عند أول تسجيل دخول ويمكن تعيين ملفات تعريف النظام لهم.

كيف يعمل تعيين الأدوار فعليًا: كل مجموعة LDAP ينتمي إليها المستخدم (وفقًا لـ roleBaseDn/ roleMemberAttribute أعلاه) تصبح "اسم دور" — وهي قيمة roleNameAttribute لتلك المجموعة (cn في المثال أعلاه). عند كل تسجيل دخول، يقارن Bastillion كل اسم من أسماء الأدوار تلك، بمطابقة نصية دقيقة، مع أسماء ملفات التعريف التي أنشأتها ضمن إدارة ← ملفات التعريف. التطابق يعيّن المستخدم إلى ذلك الملف التعريفي؛ عدم التطابق يعني عدم الوصول إلى ذلك الملف التعريفي. لذا إذا كان المستخدم عضوًا في مجموعة LDAP cn=admins,ou=groups,...، فستحتاج إلى ملف تعريف Bastillion مسمّى حرفيًا admins (بغض النظر عن حالة الأحرف — المقارنة غير حساسة لحالة الأحرف، لكن الإملاء ليس كذلك) لكي تعني تلك العضوية شيئًا في Bastillion. لا توجد خطوة تعيين منفصلة أو واجهة مستخدم لهذا — ببساطة يجب أن تتطابق الأسماء.

المستخدم الذي لا تتطابق أدواره مع أي ملف تعريف Bastillion يتم رفضه عند تسجيل الدخول (حسابات Manager هي الاستثناء الوحيد؛ فهي غير مرتبطة بملفات التعريف). عيّن defaultProfileForLdap إلى اسم ملف تعريف لتعيين كل مستخدم LDAP إليه تلقائيًا، مما يضمن قدرة الجميع على تسجيل الدخول بغض النظر عن مطابقة الأدوار — مفيد كشبكة أمان بينما لا تزال تقوم بمحاذاة أسماء ملفات التعريف مع أسماء مجموعات دليلك:```bash export DEFAULT_PROFILE_FOR_LDAP=everyone

</details>

<details>
<summary><strong>الدخول الموحّد (SAML 2.0)</strong></summary>

قم بالمصادقة عبر مزوّد هوية مؤسسي - Microsoft Entra ID أو Okta أو ADFS أو أي
مزوّد هوية SAML 2.0 - بدلاً من (أو إلى جانب) كلمات المرور المحلية أو LDAP. يظهر زر **تسجيل الدخول عبر SSO**
في صفحة تسجيل الدخول بمجرد تكوينه. قم بتمكينه:```bash
export SAML_BASE_URL=https://bastillion.example.com
export SAML_IDP_METADATA_URL=https://login.microsoftonline.com/<tenant-id>/federationmetadata/2007-06/federationmetadata.xml?appid=<app-id>

في Entra ID (أو موفّر الهوية الذي تختاره)، سجّل Bastillion كتطبيق مؤسسي / موفّر خدمة مع:

المعرّف (Entity ID): https://bastillion.example.com (أو SAML_SP_ENTITY_ID إذا تم ضبطه - انظر أدناه)
عنوان URL للرد (Assertion Consumer Service URL): https://bastillion.example.com/saml/acs

لا يتوفر لديك عنوان URL لبيانات تعريف IdP؟ قم بتكوين IdP يدويًا بدلاً من ذلك - جميع الثلاثة مطلوبة معًا في هذه الحالة:```bash export SAML_IDP_ENTITY_ID=https://sts.windows.net// export SAML_IDP_SSO_URL=https://login.microsoftonline.com//saml2 export SAML_IDP_CERT=

فقط إذا كان معرّف الكيان المسجّل في جانب IdP لا يمكن أن يطابق `SAML_BASE_URL` تمامًا:```bash
export SAML_SP_ENTITY_ID=https://bastillion.example.com

لتعيين ادعاءات مجموعات/أدوار Entra إلى ملفات تعريف Bastillion (انظر "كيف يعمل تعيين الأدوار فعليًا" أدناه قبل تغيير SAML_ROLE_ATTRIBUTE عن قيمته الافتراضية):```bash export SAML_ROLE_ATTRIBUTE=http://schemas.microsoft.com/ws/2008/06/identity/claims/groups export DEFAULT_PROFILE_FOR_SAML=everyone

يتم إضافة المسؤولين عند أول تسجيل دخول عبر SSO ويمكن تعيين ملفات تعريف النظام لهم.

**اسم المستخدم المعروض في Bastillion:** يصبح SAML NameID هو اسم المستخدم. يرسل Entra
`user.userprincipalname` افتراضيًا، وهو مناسب لأعضاء المستأجر العاديين ولكنه ينتج
اسم UPN ضيف قبيحًا مثل `alice_gmail.com#EXT#@yourtenant.onmicrosoft.com` لضيوف B2B (أي شخص
سجّل الدخول ببريد إلكتروني شخصي أو خارجي تمت إضافته كضيف). للحصول على اسم مستخدم أنظف، انتقل إلى
*Single sign-on* الخاص بتطبيق المؤسسة ← SAML ← *Attributes & Claims*، وعدّل **Unique
User Identifier (Name ID)**، وغيّر *Source attribute* الخاص به من `user.userprincipalname`
إلى `user.mail`.

**كيف يعمل تعيين الأدوار فعليًا - نفس آلية LDAP أعلاه:** يحدد `SAML_ROLE_ATTRIBUTE`
أي سمة تأكيد تحمل مجموعات/أدوار المستخدم؛ تتم مقارنة أي *قيم* تحملها تلك السمة
عند تسجيل دخول معين، **بمطابقة نصية دقيقة**، بأسماء ملفات التعريف
التي أنشأتها ضمن **Manage ← Profiles**. القيمة التي تطابق اسم ملف تعريف
تعيّن المستخدم إليه؛ لا شيء آخر في الادعاء مهم. لذا يجب تسمية ملف تعريف Bastillion
بنفس الاسم تمامًا كالسلسلة التي يرسلها التأكيد - لا توجد خطوة تعيين منفصلة
أو واجهة مستخدم، فقط يجب أن تتطابق الأسماء.

هذا هو الجزء الذي غالبًا ما يسبب الارتباك للناس مع Entra ID تحديدًا: افتراضيًا،
يمكن أن يصدر ادعاء المجموعات في Entra كل مجموعة كـ **Object ID** (GUID) بدلاً من اسم
العرض، ما لم يتم ضبط إعدادات رمز تطبيق المؤسسة صراحةً لإصدار **أسماء**
المجموعات. إذا كانت ملفات تعريف Bastillion لديك مسماة بأشياء مثل `admins`/`everyone` ولكن Entra
يرسل GUIDs، فلن يتطابق أي شيء أبدًا. تحقق من قيمة الادعاء الفعلية في تأكيد حقيقي (أو
إعدادات رمز Entra للتطبيق) قبل افتراض أن التعيين معطل - عادةً ما يكون
هذا هو السبب، وليس مشكلة من جانب Bastillion. ثلاث طرق لإصلاحه، بترتيب ما نوصي به:

1. **استخدم App Roles في Entra بدلاً من ادعاءات المجموعات (الأنظف).** ضمن تسجيل التطبيق ←
   App roles، عرّف أدوارًا بالقيم التي تريدها بالضبط (`admins`, `everyone`, ...)، ثم
   عيّن المستخدمين/المجموعات لتلك الأدوار ضمن *Users and groups* في تطبيق المؤسسة.
   هيّئ رمز SAML لإصدار ادعاء `roles`، ووجّه `SAML_ROLE_ATTRIBUTE` إلى
   URI ذلك الادعاء بدلاً من ادعاء المجموعات. أنت تختار السلسلة الدقيقة التي يرسلها Entra - لا مشكلة
   GUID على الإطلاق، وهو نموذج تفويض أنظف من إعادة استخدام مجموعات AD على أي حال.
2. **غيّر سمة المصدر لادعاء المجموعات.** تطبيق المؤسسة ← Single sign-on ←
   SAML ← *Attributes & Claims* ← عدّل ادعاء المجموعات ← هناك قائمة منسدلة
   *Source attribute*، عادةً ما تكون افتراضية على Group ID. اعتمادًا على مستأجرك وما إذا كانت المجموعات
   سحابية فقط أو متزامنة من AD محلي، قد تتمكن من تبديلها إلى `sAMAccountName`
   أو خيار اسم العرض - تختلف الخيارات الدقيقة حسب المستأجر وإصدار بوابة Entra، لذا تحقق
   مما هو معروض فعليًا بدلاً من افتراض تسمية محددة.
3. **أو لا تقاوم الأمر - سمِّ ملف تعريف Bastillion وفقًا لما يرسله Entra فعليًا.** إذا
   أصر Entra على إرسال GUID، أنشئ ملف تعريف Bastillion مسمّى حرفيًا بذلك GUID.
   أقبح، لكنه لا يتطلب أي إعادة تهيئة من جانب Entra.

يُرفض المستخدم الذي لا تتطابق ادعاءاته مع أي ملف تعريف Bastillion عند تسجيل الدخول (حسابات **Manager** هي
الاستثناء الوحيد؛ فهي غير مقيدة بملفات التعريف) - تمامًا كما هو الحال مع LDAP، لذا
يستحق `DEFAULT_PROFILE_FOR_SAML` أعلاه الضبط لنفس السبب الذي يجعل
`DEFAULT_PROFILE_FOR_LDAP` يستحق الضبط: شبكة أمان بينما لا تزال تصطف أسماء ملفات التعريف مع
قيم ادعاءات موفر الهوية لديك.

يتم تخطي فحص كلمة المرور لمرة واحدة الخاص بـ Bastillion لتسجيلات دخول SSO - يُتوقع من موفر الهوية
فرض سياسة MFA/الوصول الشرطي الخاصة به بدلاً من ذلك. لا يزال التسجيل الأولي لـ OTP
معروضًا بحيث يكون لدى مستخدمي SAML بيانات اعتماد احتياطية محلية متاحة إذا تم تعطيل SSO يومًا ما.

**الطلبات الموقعة والتأكيدات المشفرة:** يولّد Bastillion شهادة توقيع SAML الخاصة به
تلقائيًا (موقعة ذاتيًا، بنفس الطريقة التي يولّد بها شهادة TLS الخاصة به) في
أول مرة تكون مطلوبة، ويوقّع كل AuthnRequest صادر بها من ذلك الحين - لا
إعداد مطلوب، وغير ضار حتى إذا لم يتحقق موفر الهوية لديك منها. اجلب
`https://bastillion.example.com/saml/metadata` للحصول على تلك الشهادة في نموذج بيانات تعريف SP
قياسي وسلّمها لمسؤول موفر الهوية لديك إذا كان ينبغي عليهم التحقق من طلبات Bastillion الموقعة،
أو إذا كان ينبغي عليهم تشفير التأكيدات لـ Bastillion - يمكن لمعظم موفري الهوية استيراد عنوان URL لبيانات تعريف SP
مباشرةً بدلاً من لصق شهادة خام. إذا كنت تفضل استخدام زوج مفاتيح حقيقي (مثل
صادر عن CA) بدلاً من المولّد تلقائيًا، وجّه `SAML_SP_KEYSTORE_PATH`/
`SAML_SP_KEYSTORE_PASSWORD` إلى مخزن مفاتيح PKCS12 يحتوي عليه. لـ *فرض* التأكيدات
المشفرة (معطلة افتراضيًا - شغّلها فقط بمجرد تكوين موفر الهوية لديك فعليًا
للتشفير لشهادة Bastillion، أو ستبدأ كل عمليات تسجيل الدخول بالفشل):```bash
export SAML_WANT_ENCRYPTED_ASSERTIONS=true

غير مدعوم حالياً: تسجيل الخروج الأحادي (SLO) - يبقى تسجيل الخروج محلياً فقط، ولا يُخطر موفّر الهوية (IdP) أو أي تطبيق آخر كنت قد سجّلت الدخول إليه عبر نفس جلسة الدخول الموحّد (SSO). يمكن تفعيل SAML SSO إلى جانب LDAP؛ حيث يتم تقييم كلٍّ منهما بشكل مستقل، ويمكن لأيٍّ منهما إنشاء مستخدمين جدد عند أول تسجيل دخول.

التدقيق

تدقيق الجلسات مفعّل افتراضياً: يتم تخزين مخرجات الطرفية في قاعدة بيانات Bastillion ويمكن مراجعتها ضمن جلسات التدقيق (حسابات المدير فقط). يتم بث المخرجات إلى المتصفح، بحيث يمكن إعادة تشغيل حتى الجلسات التي تحتوي على كميات كبيرة جداً من مخرجات الطرفية. يُحتفظ بسجل التدقيق لمدة deleteAuditLogAfter يوماً (90 يوماً افتراضياً). يمكنك تعطيله باستخدام:```bash export ENABLE_INTERNAL_AUDIT=false

هناك أيضًا سجل تدقيق قائم على الملفات، معطّل افتراضيًا. قم بتمكينه في **log4j2.xml** عن طريق
إلغاء التعليق على:
- `io.bastillion.manage.util.SystemAudit`
- `audit-appender`

> https://github.com/bastillion-io/Bastillion/blob/main/src/main/resources/log4j2.xml#L19-L22
</details>

<details>
<summary><strong>الترقية من الإصدار v4</strong></summary>

هل تقوم بالترقية من تثبيت قديم لـ Bastillion v4 وتريد الاحتفاظ بمستخدميك وأنظمتك وملفاتك الشخصية
وسكربتاتك، والأهم من ذلك، زوج مفاتيح SSH الحالي للتطبيق بدلاً من البدء
من الصفر؟ يحتوي `tools/migrate/` على أداة ترحيل مستقلة لهذا الغرض تحديدًا — فهي تصدّر كل
جدول من قاعدة بيانات H2 القديمة (مع فك تشفير الأعمدة المشفّرة على مستوى التطبيق باستخدام
مخزن مفاتيح المثيل القديم) إلى ملف JSON، ثم تستوردها إلى مثيل v5 جديد (مع إعادة التشفير
باستخدام مخزن مفاتيح المثيل الجديد). يمكن للمستخدمين الحاليين تسجيل الدخول بكلمات المرور الحالية
فورًا بعد ذلك — دون فرض إعادة تعيين.```bash
cd tools/migrate

# 1. Export the old database
./migrate.sh export /opt/Bastillion-jetty/jetty/bastillion/WEB-INF/classes/ ~/bastillion-export.json

# 2. Start the new v5 instance once against the config dir you're migrating into, then
#    stop it (Ctrl+C) once it's finished booting - this creates the schema, jceks, and
#    default admin user.
cd ../..
java -DCONFIG_DIR=/data/bastillion/ -jar target/bastillion-5.0.0-SNAPSHOT.jar

# 3. Import into the new database (full replace of all 12 tables)
cd tools/migrate
./migrate.sh import /data/bastillion/ ~/bastillion-export.json --yes-replace-all-data

# 4. Delete the export file - it contains decrypted secrets
rm ~/bastillion-export.json

انظر tools/migrate/README.md للحصول على التفاصيل الكاملة — العثور على دليل إعدادات التثبيت القديم لديك، وما الذي يتم ترحيله بالضبط، وملاحظات الأمان حول ملف التصدير بنص عادي.