Accès conditionnel

Des règles par tenant qui autorisent, exigent une MFA ou refusent une connexion selon le réseau, l'horaire et le pays, évaluées en un point de passage unique.

L'accès conditionnel est une politique définie par organisation : une liste ordonnée de règles plus une action par défaut, appliquée à chaque connexion avant l'ouverture de toute session. Chaque règle combine jusqu'à trois dimensions (réseau, fenêtre horaire, pays) et se résout en une action : allow, require_mfa ou deny.

Comment une connexion est évaluée

Les règles sont évaluées dans l'ordre, avec une sémantique de pare-feu : la première règle active dont toutes les dimensions contraintes correspondent l'emporte. Si aucune règle ne correspond, l'action par défaut s'applique (allow si elle n'est pas définie). Une dimension vide signifie aucune contrainte : une règle sans réseau, sans fenêtre et sans pays correspond donc à toutes les connexions.

L'évaluation a lieu en un point de passage unique du flux de connexion, quel que soit le facteur primaire : mot de passe, login social, SAML ou LDAP. Un deny est en outre appliqué à l'ouverture de session, si bien que les flux passwordless et passkey ne peuvent pas non plus le contourner.

La posture privilégie la disponibilité : si le stockage de la politique est injoignable, la connexion se poursuit en allow plutôt que d'enfermer tout le monde dehors.

Les dimensions d'une règle

Réseaux

Une liste de blocs CIDR ou d'adresses IP nues (IPv4 ou IPv6). Une liste vide correspond à tout réseau.

Fenêtre horaire

Des jours de semaine (ISO, 1 pour lundi à 7 pour dimanche), une heure de début "HH:MM" (incluse) et une heure de fin (exclue), interprétées dans un fuseau IANA comme Europe/Paris (UTC si vide). Un champ vide signifie aucune contrainte sur cette partie.

Pays

Une liste de codes ISO 3166-1 alpha-2 (par exemple FR). Le pays de l'IP de connexion est résolu entièrement en local, à partir d'une base .mmdb présente sur la plateforme : aucune API de géolocalisation externe n'est jamais appelée, et l'IP de l'utilisateur ne quitte pas la plateforme. En auto-hébergement, la base se monte via GEOIP_DB_PATH, voir Configuration.

Actions

Si require_mfa s'applique à un utilisateur qui n'a aucun facteur enrôlé, la connexion est refusée : il doit d'abord enrôler un facteur depuis un réseau de confiance. Voir Authentification multifacteur.

La liste de blocage d'IP

Distincte des règles, chaque tenant dispose d'une denylist d'IP. Une IP bloquée est refusée avant même la vérification du mot de passe, et avant toute consommation des compteurs de rate-limit ou de verrouillage, avec une erreur générique qui ne divulgue rien. Elle se gère avec GET /v1/admin/ip-blocks, POST /v1/admin/ip-blocks et DELETE /v1/admin/ip-blocks/{ip}.

Impossible de s'enfermer dehors

Chaque application de la politique est vérifiée contre votre propre connexion courante. Une politique est refusée si elle produirait un deny sur votre IP actuelle, ou un require_mfa alors que votre compte n'a aucun second facteur enrôlé (le step-up serait impossible, vous seriez donc verrouillé à votre prochaine connexion). Le message d'erreur vous invite à ajouter une règle d'autorisation pour votre réseau ou à enrôler un facteur d'abord. Ce garde-fou s'exécute aussi lors de la restauration d'une version antérieure.

Gérer la politique par l'API

Les deux endpoints exigent la permission tenant:manage, avec un jeton d'API admin (Authorization: Bearer obx_...). Si votre organisation utilise un domaine personnalisé, il remplace accounts.obexal.com.

curl -sS https://accounts.obexal.com/v1/admin/access-policy \
  -H "Authorization: Bearer $OBEXAL_API_TOKEN"

{
  "policy": {
    "rules": [
      {
        "name": "Bureau et VPN",
        "networks": ["203.0.113.0/24", "198.51.100.7"],
        "action": "allow",
        "enabled": true
      }
    ],
    "defaultAction": "require_mfa"
  },
  "knownActions": ["allow", "require_mfa", "deny"]
}

curl -sS -X PUT https://accounts.obexal.com/v1/admin/access-policy \
  -H "Authorization: Bearer $OBEXAL_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "rules": [
      {"name": "Bureau et VPN", "networks": ["203.0.113.0/24"], "action": "allow", "enabled": true},
      {"name": "Heures ouvrées", "networks": [], "action": "allow", "enabled": true,
       "window": {"days": [1, 2, 3, 4, 5], "start": "07:00", "end": "20:00", "tz": "Europe/Paris"}}
    ],
    "defaultAction": "deny"
  }'
# 204 No Content : appliquée, auditée, archivée comme nouvelle version

Chaque application est consignée au journal d'audit et archivée comme version immuable : voir Versions et simulation de politique. La politique d'accès fait aussi partie du bundle de configuration déclaratif, voir Policy as code.

Limites

• Au plus 100 règles par politique, 256 réseaux et 250 pays par règle.
• Les noms de règle sont limités à 120 caractères.
• Les règles par pays ne s'appliquent que si une base GeoIP locale est installée et lisible.