dacs - En ligne dans le Cloud

PROGRAMME:

Nom

dacs - un système de contrôle d'accès distribué

SYNOPSIS

dac [-v | --verbeux] [--dumpenv] [--Licence] [--version]

dac dacs-commande [options dacs[1]] [...]

dacs-commande [-u uri-préfixe | -uj nom-juridiction | A | -up nom-juridiction | -nous]
[-c dacs.conf]
[-sc site.conf] [-ll niveau de journalisation] [-format fmt] [-q] [-t] [-Dprénom=Plus-value]
[-v | --verbeux] [--dumpenv] [--enable-dump] [--Licence] [--std] [--version]

DESCRIPTION

Ce programme fait partie du DACS suite.

DACS est un système d'authentification et de contrôle d'accès Web à usage général. Il offre
fonctionnalité d'authentification unique et contrôle d'accès flexible au contenu et aux services fournis
par des serveurs Web. DACS se compose d'un Apache module (mod_auth_dacs[2]) par lequel Apache
communique avec DACS pour prendre des décisions de contrôle d'accès, une suite de programmes CGI qui
fournir DACS services Web et une collection de commandes utilitaires qui fournissent divers
fonctions de support et d'administration pour DACS. Certains de ces utilitaires, tels que
dacshttp(1)[3] et client ssl(1)[4], sont complètement polyvalents.

Votre DACS le moteur de contrôle d'accès et les composants d'authentification peuvent également être utilisés à partir du
ligne de commande, dans un environnement CGI ou complètement indépendamment du Web.

Pour des informations importantes sur DACS, y compris les instructions d'installation, veuillez consulter
dacs.readme(7)[5] et dacs.installer(7)[6].

À propos DACS
NON GARANTIE
Ce logiciel est fourni par Dss "en l'état" et toute garantie expresse ou implicite,
y compris, mais sans s'y limiter, les garanties implicites de qualité marchande, d'adéquation
un but particulier, ou la non-contrefaçon, sont exclus. En aucun cas Dss ne sera
responsable de tout dommage direct, indirect, accessoire, spécial, exemplaire ou consécutif
les dommages (y compris, mais sans s'y limiter, l'achat de biens ou de services de substitution ;
perte d'utilisation, de données ou de bénéfices ; ou interruption d'activité) quelle qu'en soit la cause et à tout
théorie de la responsabilité, qu'elle soit contractuelle, stricte ou délictuelle (y compris
négligence ou autre) résultant de quelque manière que ce soit de l'utilisation de ce logiciel, même si
informé de la possibilité de tels dommages.

Par convention, les noms de tous DACS les services Web commencent par le préfixe "dacs_" (par exemple,
dacs_conf). À partir de la version 1.4.17, toutes les commandes qui implémentent DACS
commencer par le préfixe "dacs" (par exemple, dacsconf). Beaucoup DACS les services Web ont la commande
analogues. Les noms des services Web utilisés en interne par DACS (c'est-à-dire qu'ils sont
jamais appelé directement par les utilisateurs) commencent par "local_" (par exemple, local_passwd_authenticate).
Les services Web et les commandes à usage général ne suivent pas de convention de dénomination, autre que
n'utilisant aucun des préfixes mentionnés précédemment.

Les définitions de type de document (DTD) qui sont conservées dans le répertoire dtd-xsd sont utilisées
pour documenter les formats de fichiers ou décrire les arguments à un DACS service Web ou sa réponse. Dans
l'implémentation actuelle, ces fichiers DTD ne sont pas utilisés lors de la validation XML. Les attributs
de type CDATA peuvent avoir des contraintes supplémentaires sur leurs valeurs ; consulter les correspondants
Documentation. Les fichiers ne sont techniquement pas des DTD valides, car il leur manque un type de document
déclaration (DOCTYPE); un DOCTYPE approprié est généré par programme au moment où un
La DTD est émise.

Important
DACS n'empêche pas certains types d'attaques contre des sites Web, tels que Denial of
service attaques[7] Intersite script (XSS)[8] ou Intersite nécessaire contrefaçon
(CSRF)[9]. Cependant, lorsqu'il est associé à des mesures de protection appropriées du site Web, DACS
fournit des mécanismes pour rendre ces types d'attaques plus difficiles.

À propos le Manuel Pages
La documentation technique de DACS se compose d'un ensemble de pages de manuel. Dans le HTML
collection, un indice page[10] comprend une table des matières, des liens vers des annotations spéciales
dans la documentation technique, et les listes de variables, les directives de configuration et
Définitions de types de documents XML.

Conseil
Chaque page de manuel HTML contient un outil de sélection de taille de police près de son bas. Si
JavaScript est activé, la taille de police actuellement sélectionnée peut être modifiée et un
ensemble de préférences. Pour choisir une taille de police pour la page en cours, cliquez sur l'un des quatre
des boites. Pour faire de la sélection actuelle votre préférence sur les pages de manuel, les visites de sites,
et les sessions du navigateur, cliquez sur le bouton « définir », qui définira un cookie HTTP. Si un
la préférence n'a pas été définie de cette manière (c'est-à-dire qu'il n'y a pas de cookie) et une page de manuel
est visité avec le paramètre de requête DACSMANFONT réglé sur 0, 1, 2 ou 3 (représentant
les plus petites aux plus grandes tailles de points), la police correspondante sera sélectionnée et le
préférence définie automatiquement (si une préférence a été définie, le paramètre est ignoré).

Les zones de la documentation intitulées « Sécurité » traitent de considérations de sécurité importantes ;
veuillez leur porter une attention particulière. Les zones étiquetées « Astuce » fournissent des indicateurs pour gagner du temps
techniques (et parfois de réduction de l'aggravation) et pratiques recommandées.

Dans les chemins d'accès et les URL qui apparaissent dans les exemples, le texte "..." représente le texte qui a
été omis parce qu'il n'est pas pertinent pour la discussion en cours, ou qui peut varier
selon les détails de la configuration, comme l'endroit où quelque chose a été installé (par exemple,
.../dacs/bin/dacshttp).

Sauf indication contraire, les URL utilisées dans les exemples sont fictives et ne seront probablement pas
travail. Le nom de domaine réservé example.com est souvent utilisé (RFC 2606[11]).

Dans les instructions et les exemples, un « % » est généralement utilisé pour signifier une invite de ligne de commande :

% Date
Dim 1 avr. 15:33:11 PDT 2007

Parfois, un autre caractère est utilisé pour signifier une invite, cependant, comme lorsque
démonstration du mode interactif de dacsexpr(1)[12]:

> 1 + 1
2

Une forme étendue de BNF notation[13] est utilisé pour décrire la syntaxe de manière concise. Nous espérons que c'est
à la fois compréhensible et familier, mais certaines incohérences et ambiguïtés peuvent survenir
tout au long de la documentation ; cela s'améliore lentement. Un terme dans une production peut
inclure une spécification de type d'expression régulière, avec '+' signifiant une ou plusieurs occurrences
du terme, et '*' zéro ou plusieurs occurrences. N'importe lequel d'un ensemble de caractères est spécifié
entre crochets, et une plage de caractères consécutifs (en séquence de code ASCII) est
séparés par un tiret (par exemple, [A-Za-z0-9\-_]+ signifie "un ou plusieurs caractères alphabétiques,
chiffres, tirets ou traits de soulignement"). Dans d'autres contextes, les crochets indiquent une option
terme. Les guillemets simples et doubles spécifient des caractères littéraux. Notez que les DTD XML utilisent leur
propre syntaxe, qui est quelque peu différente, et dans certains cas des grammaires suivies dans les
Les RFC sont respectées par souci de clarté ou dans des exemples.

ACTIVITES Concepts
Certains des concepts clés utilisés tout au long de la DACS documentation sont définis dans ce
.

Compte
Un enregistrement persistant qui associe une identité (ou un nom d'utilisateur) à des informations d'état
sur le compte (par exemple, si le compte est activé ou désactivé), des informations
qui est requis pour authentifier l'identité (comme un résumé d'une chaîne de mot de passe),
et éventuellement d'autres informations relatives à la connexion. Noter que DACS les identités ne
avoir nécessairement un compte correspondant. DACS ne fournit pas de mécanismes pour
administrer les types de comptes « étrangers » ; par exemple, bien qu'il puisse s'authentifier contre
eux, il ne peut pas créer ou répertorier les comptes Unix ou Windows.

protocoles d'authentification
La procédure par laquelle une personne ou un programme obtient des titres de compétences qui représentent un DACS
identité, généralement en affirmant une DACS nom d'utilisateur qui représente une identité et
fournir des informations que seule cette identité est susceptible de connaître ou de posséder. Après
authentification réussie, on dit qu'une personne ou un programme s'est authentifié. DACS
peut s'interfacer avec une grande variété de méthodes d'authentification et fournit certains de ses
posséder; de nouvelles méthodes peuvent facilement être ajoutées.

autorisation
La procédure qui détermine, dans un contexte particulier, si une demande pour un
la ressource ou l'objet doit être autorisé. Si une identité est autorisée à effectuer une
certaine opération sur l'objet, l'accès est accordé, sinon il est refusé. Accès
les règles de contrôle sont une méthode pour décrire quelle(s) identité(s) doivent être
accordé - ou refusé - l'accès à une ressource particulière. Contrôle d'accès grossier
implique de prendre une décision de haut niveau quant à savoir si l'accès à un objet doit être
accordé; il s'agit généralement d'une décision de tout ou rien. Un contrôle d'accès précis est
utilisé dans un programme pour décider si l'accès à une ressource de niveau inférieur (certaines données,
une fonction administrative, un menu) devraient être accordés.

Notez que contrairement à certains systèmes, DACS ne prédétermine pas quelles ressources un
l'utilisateur (identité) peut et ne peut pas accéder ; c'est-à-dire qu'un administrateur ne fait pas de liste
des droits de chaque utilisateur. L'autorisation est toujours déterminée par l'évaluation des règles,
en temps réel, lorsqu'un utilisateur demande une ressource. Les seules exceptions à cette règle sont certaines
caractéristiques optionnelles: Autorisation Cache haute performance [14] et Liens[15].

Lettres de créance
If protocoles d'authentification est réussi, DACS renvoie des informations qui peuvent être utilisées dans
opérations ultérieures pour représenter l'identité authentifiée. Les identifiants contiennent
des informations sur l'identité, telles que son nom, et des méta-informations, telles que le
moment auquel les informations d'identification expirent et deviennent invalides. Les identifiants sont protégés
cryptographiquement afin qu'ils soient difficiles à falsifier ou à modifier. Ils doivent être conservés
secret, de sorte que l'identité ne peut être utilisée par personne d'autre que son propriétaire, et doit
accompagner une requête faite à un serveur afin que DACS sait qui fait la demande. Les
le mécanisme particulier utilisé pour cela n'est pas important à condition que les informations d'identification ne puissent pas être
copié et réutilisé; transport des informations d'identification à l'aide de la charge utile d'un cookie HTTP sur
une connexion SSL est typique, bien que l'envoi d'informations d'identification en tant que valeur d'un HTTP
l'en-tête d'extension est une autre possibilité.

Bien qu'il n'y ait pas de limite spécifique sur la taille des informations d'identification dans la mesure où DACS is
concernés, car ils peuvent être encapsulés dans un cookie HTTP et renvoyés à un
navigateur, les contraintes sur les cookies imposées par les navigateurs doivent être soigneusement examinées.

Toute juridiction peut comprendre les informations d'identification produites par toute autre juridiction au sein de
la même fédération. Par conséquent, un utilisateur n'a besoin d'être authentifié qu'une seule fois pour accéder
services Web dans toute juridiction utilisant cette identité.

Notez que dans DACS, les informations d'identification ne confèrent aucun droit à leur propriétaire ni ne transmettent aucun
autorisation; DACS n'est pas un basé sur les capacités Système[16]. Les informations d'identification représentent simplement
a DACS identité.

Reportez-vous à dacs_authentifier(8)[17] pour plus de détails.

actuel nécessaire
L'événement qui a déclenché le contrôle d'autorisation en cours de traitement par
dacs_acs(8)[18] est appelée la demande actuelle. Pour une demande de
DACS-ressource Web enveloppée, ce sera la requête HTTP reçue par le Web
serveur pour la ressource. Dans des situations où dacs_acs n'est pas impliqué, comme lorsque
vérification dacs(1)[19] ou dacsexpr(1)[12] sont utilisés, la requête en cours et son contexte sont
spécifiés par des arguments de ligne de commande ou sont obtenus à partir du efficace
sûr, heureux et sain[20].

dacs_acs Usages ${DACS::URI} comme composant de chemin de la requête actuelle. Il est
obtenu d'Apache Links élément du request_rec actuel. C'est la chaîne qui
est utilisé pour faire correspondre les règles de contrôle d'accès.

Autre DACS les composants déterminent la requête HTTP actuelle en examinant plusieurs
Variables d'environnement: HTTP_HOST (ou SERVER_NAME et SERVER_PORT), REQUEST_URI,
QUERY_STRING et HTTPS.

La valeur de ${DACS::URI} et la composante chemin de ${Env::REQUEST_URI} ne sont pas
forcément le même. Après une redirection interne par exemple, la valeur de cette dernière est
à partir de l'URL d'origine, tandis que la première provient de la cible de la redirection.

La chaîne de requête actuelle est importante car elle peut être utilisée pour déterminer le
actuel fédération[21] et actuel juridiction[22], et parce qu'il est utilisé lorsque
rechercher la règle de contrôle d'accès à appliquer à la demande.

DACS
Composé de services Web basés sur CGI, un Apache module 2.0/2.2, et une collection de
utilitaires, DACS fournit des fonctionnalités d'authentification et d'autorisation. Transparent,
Un contrôle d'accès basé sur les rôles à granularité grossière est disponible pour les ressources Web.

Le contrôle d'accès programmatique et généraliste basé sur les rôles est disponible pour pratiquement n'importe quel
programme (en utilisant vérification dacs(1)[19]). Ceci est complètement découplé d'Apache.

DACS administrateur
Une personne (ou des personnes) responsable de la gestion de l'exploitation de DACS is
appelé un DACS administrateur (parfois simplement "l'administrateur"). Cet individu est
pas nécessairement un administrateur système (par exemple, superutilisateur ou root), bien qu'un petit
nombre de composants optionnels de DACS doit s'exécuter en tant qu'utilisateur ou groupe root. Les DACS
l'administrateur n'a pas besoin d'être un Apache administrateur; une fois que Apache a été configuré pour
DACS il nécessite généralement très peu de modifications par la suite. Les DACS administrateur
est responsable de la configuration et des tests DACS (probablement l'installer et le mettre à jour,
aussi), la gestion des comptes utilisateurs et des règles de contrôle d'accès, la sauvegarde de la sécurité, la sauvegarde
des fichiers de configuration et de données, etc. La conception de DACS permet une certaine délégation
de responsabilité, en grande partie basée sur les autorisations de fichier. Lorsqu'il est invoqué en tant que service Web,
chacune des identités configurées comme un ADMIN_IDENTITY[23] est effectivement un DACS
administrateur; dans ce contexte, le superutilisateur du système n'a aucune importance.

DACS identité
Chaque utilisateur authentifié se voit attribuer un nom composé du nom du
juridiction d'authentification, son nom de fédération et un nom d'utilisateur. Chacun de ces noms
les composants doivent être syntaxiquement corrects. Dans certains contextes, le nom de la fédération est
implicite; parfois, le nom de la juridiction est également implicite. Des entités telles que
individus (personnes, mais aussi programmes, dispositifs, etc.), fédérations, juridictions,
et les groupes ont des noms. Il appartient aux juridictions d'authentifier
utilisateurs. La syntaxe, les significations et l'unicité des noms est également une question de compétence,
et peut-être aussi un problème à l'échelle de la fédération.

Chaque entité du monde réel a généralement un DACS l'identité, mais cela est laissé à
juridictions d'authentification. Deux ou plusieurs identités sont distinctes si elles ne renvoient pas
au même individu du monde réel. L'identité fédérée ou l'authentification unique (SSO) est le
capacité de reconnaître une identité d'utilisateur à travers les juridictions et même à travers les fédérations.

Important
Gardez à l'esprit que quelle que soit la méthode d'authentification et les informations de compte
utilisé, deux identifiants identiques (relatifs à la même juridiction et tenant compte
Compte NAME_COMPARE[24]) sont implicitement assumé à reportez-vous à le même identité by
DACS. Par exemple, quelqu'un qui s'est authentifié en tant qu'auggie en fournissant le bon
Le mot de passe Unix est pratiquement impossible à distinguer de quelqu'un qui s'est authentifié en tant que
auggie à l'aide d'une carte d'information. Les informations d'identification de l'utilisateur incluent des informations sur le
méthode d'authentification impliquée dans leur création et la utilisateur()[25] la fonction peut
être utilisé pour obtenir ces informations, mais il serait imprudent de fonder les identités sur
cette. Il est fortement conseillé qu'un nouveau DACS juridiction élaborent soigneusement un
plan extensible pour le nommage des utilisateurs.

DACS-enveloppé
On dit qu'une ressource Web est DACS-encapsulé si le serveur Web responsable du
appels de ressources DACS (plus précisement, dacs_acs(8)[18]) pour faire un contrôle d'accès
décision chaque fois qu'il reçoit une demande de ressource.

fédération
A DACS fédération se compose d'une ou plusieurs juridictions. Les juridictions comprenant
une fédération coordonne le partage d'informations grâce à des pratiques commerciales légères
mis en œuvre comme condition d'adhésion à un DACS fédération; en d'autres termes, le
les membres d'une fédération acceptent généralement d'observer certaines règles de conduite pour
préserver la sécurité globale et que les utilisateurs puissent en tirer le maximum d'avantages. Une fédération
composé d'une seule juridiction n'est pas inhabituel.

Articles type
Un type d'élément est un nom qui correspond à un VFS[26] (magasin de fichiers virtuel) spécification qui
configure comment et où les données sont stockées. Le niveau d'indirection qu'ils fournissent
signifie que les règles de contrôle d'accès, par exemple, peuvent être configurées pour être en
fichiers, une base de données Berkeley DB, une base de données distante accessible par HTTP, et ainsi de suite - tous
ce qui est requis est que le type d'élément acls soit correctement configuré. Certains types d'articles
(comme acls) sont réservés et ont une signification particulière pour DACS, tandis que d'autres peuvent être utilisés par
a DACS administrateur à d'autres fins. Un nom de type d'élément est sensible à la casse et
se compose de caractères alphanumériques, de tirets et de traits de soulignement, mais doit commencer par une lettre alphabétique
caractère.

juridiction
A DACS juridiction est une entité administrative autonome qui authentifie sa
utilisateurs, fournit des services Web, ou les deux. Il peut correspondre à une organisation,
service, serveur Web ou hôte virtuel. Les juridictions sont parfois créées simplement comme
une commodité administrative. Chaque juridiction se voit attribuer un nom unique dans un
fédération.

La juridiction d'origine d'un utilisateur est une juridiction qui peut authentifier cet utilisateur. Dans
situations où un utilisateur dispose de plusieurs informations d'identification obtenues de différents
juridictions, la juridiction d'origine effective d'une demande dépend de
les informations d'identification sont sélectionnées lors du traitement de l'autorisation. Les directives de configuration sont
disponible pour restreindre le nombre d'ensembles d'informations d'identification pouvant accompagner une demande.

utilisateur agent
Un agent utilisateur est un logiciel côté client qui interagit avec d'autres logiciels (un serveur
demande, généralement) au nom d'un utilisateur. Un utilisateur est souvent une personne mais peut aussi être
Logiciel. Un navigateur Web, qui est utilisé pour interagir avec un serveur Web, est un exemple de
un agent utilisateur.

Nomination
DACS doit nommer une variété de choses afin qu'elles puissent être mentionnées dans des expressions,
règles de contrôle d'accès, directives de configuration, etc. Alors que la syntaxe d'URI est utilisée pour
nommer certains types d'objets dans DACS, DACS a également ses propres schémas de nommage concis.

Notes
Les termes fédération actuelle (juridiction actuelle) et cette fédération (cette
juridiction) sont utilisés dans la documentation pour désigner la fédération (juridiction)
associé au contexte de configuration en vigueur alors que DACS traite une demande.

En général, le nom-fédération le composant d'un nom est facultatif ; en cas d'absence, le
la fédération actuelle est supposée. De même, le nom-juridiction peut être élidé et le
compétence actuelle est implicite.

Fédérations
syntaxe:

nom-fédération::

Mise en situation :

DÉMO ::

Votre nom-fédération (généralement obtenu auprès d'un FÉDÉRATION_NAME[27] configuration
directive) doit commencer par un caractère alphabétique et est suivi de zéro ou plus
caractères alphanumériques, tirets et traits de soulignement. UNE nom-fédération est un cas ordinairement traité
avec sensibilité (mais voir le NAME_COMPARE[24] directive de configuration et la utilisateur()
fonction pour des comportements alternatifs). Il n'y a pas a à priori limite sa longueur.

Votre FEDERATION_DOMAIN[28] précise le suffixe du nom de domaine commun à tous
juridictions dans une fédération.

Juridictions
syntaxe:

[[nom-fédération:: | [::]] nom-juridiction:

Exemples :

DÉMO::DSS:
::DSS :
DSS :

Votre nom-juridiction (généralement obtenu auprès d'un JURIDICTION_NAME[29] configuration
directive) doit commencer par un caractère alphabétique et est suivi de zéro ou plus
caractères alphanumériques, tirets et traits de soulignement. UNE nom-juridiction est habituellement traité
cas sensible (mais voir le NAME_COMPARE[24] directive de configuration et la
utilisateur()[25] pour les comportements alternatifs). Il n'y a pas a à priori limite sur son
longueur.

Utilisateurs
syntaxe:

[[[nom-fédération:: | [::]] nom-juridiction]:Nom d'utilisateur

Exemples :

DÉMO::DSS:auggie
:: DSS: Auggie
DSS : auggie
:auggy

Une pleine DACS l'identité comprend un composant de nom de fédération et un nom de juridiction
composant, en plus de la Nom d'utilisateur. Il est fourni à DACS-programmes enveloppés comme le
valeur de la DACS_IDENTITÉ[30] variable d'environnement.

Le composant nom d'utilisateur, qui est disponible pour les programmes CGI en tant que valeur du
DACS_USERNAME[31] variable d'environnement, se compose d'un ou plusieurs caractères ASCII de
l'ensemble des lettres majuscules et minuscules, des chiffres et la ponctuation suivante
personnages:

! # $ % & ' - . ; ? @ [ ^ _ ` { }

Tous les caractères ayant une valeur inférieure à 041 (octal) ou supérieure à 0176 (octal) sont
invalide, ainsi que les caractères suivants :

* , : + ( ) ~ < > = | \ / "

Remarques
· En plus des caractères alphanumériques, RFC 2396[32] n'autorise que le
caractères suivants ("pchar") pour apparaître dans le composant chemin d'un URI :

- _ . ! ~ * ' ( ) % : @ & = + $ ,

· Certaines adresses e-mail valides ne sont pas valides DACS noms d'utilisateur. Par exemple,
*bob*@example.com, "(bob)"@example.com et \(bob\)@example.com sont valides
noms de boîtes aux lettres tels que définis par RFC 822[33] (Annexe D) et discuté dans RFC
3696[34] (Section 3), mais les deux sont invalides car DACS noms d'utilisateur. Sauf cité,
le composant de la partie locale d'une adresse e-mail, qui précède le caractère "@"
dans l'addr-spec, ne peut contenir aucun des éléments suivants :

( ) < > @ , ; : \ " . [ ]

De plus, l'espace et tous les caractères de contrôle US-ASCII (octets 0 - 31)
et DEL (127) ne sont pas autorisés. Sans guillemets, la partie locale peut consister en
toute combinaison d'alphabets, de chiffres ou de l'un des caractères suivants :

! # $ % & ' * + - / = ? ^ _ ` . { | } ~

Un point ("".") peut être utilisé, mais ne peut pas commencer ou terminer la partie locale, ni
deux périodes consécutives ou plus apparaissent. Entre guillemets, tout ASCII
caractère peut apparaître s'il est correctement cité (par exemple, Auggie."
".O."\'".Toutou@exemple.com). La longueur maximale de la partie locale est de 64
caractères et la longueur maximale du composant de domaine qui apparaît après
le caractère "@" est de 255 caractères.

Il n'y a actuellement aucun moyen de « citer » un DACS nom d'utilisateur, donc un encodage sûr
méthode ou transformation doit être appliquée à ces noms.

· DACS peut créer des identités à usage interne ayant des composants de nom d'utilisateur qui
inclure des caractères qui sont normalement invalides.

· UNE Nom d'utilisateur est sensible à la casse (mais voir le NAME_COMPARE[24] configuration
directive et la utilisateur()[25] pour les comportements alternatifs). Il n'y a pas a
à priori limite sa longueur.

· La pratique recommandée est que les juridictions cartographient leurs DACS noms d'utilisateur à
minuscules lors de la procédure d'authentification lorsque cela est possible et lorsque le
les mappages sont uniques. Les SORTIR*[35] peut être utilisé à cette fin.

Groupes
syntaxe:

[[nom-fédération:: | [::]] %[nom-juridiction]:nom de groupe

A nom de groupe doit commencer par un caractère alphabétique et peut être suivi de n'importe quel nombre
de caractères alphanumériques, tiret ("-") et trait de soulignement ("_").

Exemples :

%DEMO::DSS:amis
%::DSS:amis
%DSS:amis
%:copains

Rôles et descripteurs de rôle
syntaxe:

Descripteur de rôle -> Chaîne vide | Liste de rôles

Liste de rôles -> Rôle | Rôle "," Liste de rôles

Rôle -> Rôle de base | Composite-Rôle

Rôle de base -> [A-Za-z0-9\-_]+
Composite-Rôle -> Rôle de base "/" Rôle de base | Rôle de base "/" Composite-Rôle

Chaîne vide -> ""

Une chaîne de descripteur de rôle (également appelée chaîne de rôle ou descripteur de rôle) se compose de
une liste de rôles séparés par des virgules. Le nom d'un rôle (un Rôle de base) est construit à partir de
lettres majuscules et minuscules, chiffres, tirets et traits de soulignement. UNE Composite-Rôle is
construit à partir de deux ou plus Rôle de base termes, séparés par une barre oblique. Ici
sont trois exemples de descripteur de rôle :

admin, roue, racine
administrateur/matériel
réseaux/programmation,informatique/systèmes/Project_X

Notes
Une chaîne de descripteur de rôle ne contient aucun caractère d'espace et ne peut pas commencer ou
terminer par une virgule ou une barre oblique. Deux virgules consécutives ou plus sont illégales,
tout comme deux ou plusieurs barres obliques consécutives.
Votre setvar()[36] peut être utilisée pour séparer un rôle composite en son
rôles.

S'il vous plaît se référer à dacs.groupes(5)[37] pour plus d'informations.

Syntaxe utilisateur concise
syntaxe:

ident -> '{' liste-kwv '}' | utilisateur
liste-kwv -> kWv [',' kWv]*
kWv -> kwv-utilisateur | groupe-kwv | kwv-attr | kwv-ip | kwv-expire
kwv-utilisateur -> 'u=' [Q] utilisateur [Q]
groupe-kwv -> 'g=' [Q] groupes [Q]
kwv-attr -> 'a=' [Q] attribut [Q]
kwv-expire -> 'e=' [Q] expire [Q]
kwv-ip -> 'ip=' [Q] adresse IP [Q]

utilisateur -> nom-simple | Identité DACS
groupes -> groupe [',' groupe]*
groupe -> nom de groupe | descripteur de rôle
attribut -> tout-alphabétique
adresse IP -> n'importe quelle adresse IP
expire -> +secondes-rel | données

où:

· Q est un caractère de guillemet facultatif (correspondant) ;

· des espaces peuvent éventuellement précéder la plupart des jetons ;

· une Identité DACS est un entier ou abrégé DACS identité

· une nom-simple est le Nom d'utilisateur composant d'un DACS identité (c'est-à-dire sans aucune
deux-points); par conséquent, dans ce contexte, un nom "spécial", tel que auth, est traité
comme :auth

· descripteur de rôle doit être valide DACS chaîne de rôle et nom de groupe doit être valide
DACS nom du groupe (voir dacs_authentifier(8)[39] et dacs.groupes(5)[cinq]);

· une adresse IP est exprimée dans la notation numérique standard Internet (par exemple,
10.0.0.1); et

· la durée de vie des informations d'identification dérivées de l'identité peut être exprimée soit sous la forme d'un
nombre de secondes donné (par exemple, "e=+3600") ou une date donnée dans l'un des éléments suivants
formats (voir l'heure du strp(3)[41]) :

%a, %d-%b-%Y %H:%M:%S GMT
%d-%b-%Y
%b %d, %Y
%b %d
%Y-%m-%dT%H:%M:%SZ

Si nécessaire, les dates sont interprétées par rapport à l'heure ou à la date actuelle. Les
la durée de vie est convertie en sa forme canonique, qui est l'heure et la date absolues
en secondes depuis l'époque, sur la base de l'horloge de la juridiction. Une date dans le passé
peut être spécifié; cela peut être utile pour les tests, par exemple. Si l'identité
n'est pas utilisé pour créer des informations d'identification, la date d'expiration est ignorée, bien qu'elle doive être
syntaxiquement correcte.

· la seule valeur d'attribut prise en charge est "a", ce qui signifie que l'identité doit être
traité comme un ADMIN_IDENTITY[23] (se référer au -administrateur drapeau de vérification dacs(1)[19]).

Un nom exprimé dans la syntaxe concise, donne un nom d'utilisateur et, éventuellement, des rôles et
attributs pour l'identité. Il est utilisé par vérification dacs(1)[19], par exemple.

Votre dac Utilité
DACS les commandes utilitaires sont généralement installées sous forme de binaires séparés, mais DACS peut (aussi ou
à la place) être construit avec la plupart d'entre eux combinés en un seul binaire qui est installé comme
dac. Les différents programmes utilitaires peuvent alors être exécutés comme :

% de ca dacs-commande [options dacs] [options-commande]

Par exemple :

% dacs dacskey -u fichier de sortie foo.myfed.com

Exécuter le dac L'utilitaire sans arguments affichera la liste des sous-commandes disponibles.

Démarrage Gestion
pont DACS les programmes effectuent les actions suivantes lorsqu'ils démarrent :

1. Déterminer le « mode » dans lequel ils doivent fonctionner ; par exemple, si le REMOTE_ADDR
variable d'environnement est présente, les programmes supposeront en général qu'ils doivent s'exécuter en tant que
application Web plutôt que comme commande utilitaire

2. Traitez un ensemble standard d'arguments de ligne de commande (options dacs[dix])

3. Définissez le processus umask sur 007 pour interdire l'accès mondial à tous les fichiers créés.

4. Désactivez un vidage de mémoire afin que les informations sensibles ne puissent pas être révélées en les examinant
(mais voir --enable-dump[dix])

5. Refuser d'opérer si un fichier de configuration est introuvable ou comporte une erreur

6. Pour les services Web, faites DACS répertoire personnel le répertoire de travail courant

7. Si le "mode sécurisé" a été activé, les services Web ne traiteront que les requêtes HTTPS

8. Vérifiez que la version requise par une requête est compatible avec la version de DACS
réception de la demande

9. Traitez tous les arguments de ligne de commande spécifiques au programme.

DACS programmes s'efforcent de détruire les informations sensibles (telles que les mots de passe) dès
car il n'est plus nécessaire et de ne pas écrire d'informations potentiellement sensibles dans les fichiers journaux
sauf si spécifiquement configuré pour le faire.

Internals
Certain DACS les composants peuvent appeler d'autres composants en utilisant HTTP (éventuellement via SSL, selon
configuration). Par exemple, les modules d'authentification peuvent être invoqués en tant que services Web par
dacs_authentifier(8)[39]. Dans tous les cas, ces appels HTTP "internes" peuvent ne pas aboutir à un
redirection, par exemple via un code d'état 302 Found. Bien que cela puisse parfois être un
inconvénient, c'est en partie une mesure de sécurité.

Conseil
Lors du débogage d'un problème pouvant impliquer une requête HTTP interne (notamment liée
à l'authentification), vérifiez que DACS ne reçoit pas de redirection. HTTP interne
les demandes peuvent également échouer mystérieusement en raison d'une configuration incorrecte ou incomplète
des paramètres SSL. Requêtes HTTP internes via SSL client ssl(1)[4], tout comme le
dacshttp(1)[3] commande. Si vous pensez qu'une URL basée sur https peut ne pas fonctionner,
déboguer le problème en utilisant client ssl et alors dacshttp.

Pour maintenir la cohérence des données, DACS crée des serrures exclusives à l'aide du fctl(2)[44] système
faire appel à des fichiers écrits dans le répertoire configuré via le TEMP_RÉPERTOIRE
Directive.

Journal
pont DACS les services et utilitaires écrivent divers types de messages dans un ou plusieurs fichiers journaux.
Ces messages peuvent être inestimables lorsque vous essayez de comprendre ce que DACS fait, pour
audits de sécurité, ou pour voir DACS-les ressources emballées sont accessibles et dans quel
façons.

S'il vous plaît se référer à dacs.conf(5)[46] pour plus d'informations sur les directives de configuration liées à
enregistrement. Un assortiment d'indicateurs de ligne de commande, décrits ci-dessous, sont également liés à
enregistrement.

Notes
· DACS peut émettre des messages de journal avant la fin du traitement de la configuration et
les directives de configuration associées à la journalisation ne sont pas en vigueur pendant cette
intervalle de démarrage.

· Parce que mod_auth_dacs[2] est un Apache module, le Apache les directives de journalisation s'appliquent
à elle (et non à la DACS directives) et ses messages de journal sont écrits dans Apache enregistrer
fichiers.

· Les fichiers journaux peuvent rapidement devenir volumineux, en particulier lorsque le niveau de journalisation est défini sur
niveaux de débogage ou de trace. Envisagez une rotation ou une troncature quotidienne.

· Le texte d'un message de journal peut parfois s'étendre sur plusieurs lignes.

La valeur par défaut du LOG_FORMAT[47] directive, qui contrôle l'apparition de log
messages, est défini dans include/local.h comme LOG_FORMAT_DEFAULT_WEB pour DACS services Web
et LOG_FORMAT_DEFAULT_CMD pour tout le reste. Voici un message de journal typique :

[Mer 12 juil 12:37:09 2006] [trace] [83648,1060,-] [dacs_acs:"acslib"] Autoriser
clause accorde l'accès

Audit-Classe Historique Messages
Dans le cas des messages de classe d'audit, une chaîne entre parenthèses peut parfois suivre
une identité, comme dans les exemples ci-dessous. Cette chaîne, appelée tracker, associe log
messages avec une origine particulière et peut être utilisé pour tracer la séquence d'un utilisateur de
demandes de service à l'aide de messages de journal dans l'ensemble d'une fédération. Cela peut être utile lorsque
le débogage, la recherche de problèmes de sécurité ou l'analyse médico-légale.

Pour un utilisateur non authentifié, le tracker ne peut être dérivé que de manière heuristique, à partir de
éléments du contexte d'exécution. L'adresse IP de l'utilisateur, la chaîne de l'agent utilisateur et SSL
le certificat client, lorsqu'il est disponible, est utilisé. Si deux de ces chaînes de suivi diffèrent,
les demandes proviennent généralement de différents hôtes, navigateurs ou utilisateurs, mais cela
n'est pas forcément toujours le cas. De même, si la même chaîne de suivi est
associé à deux messages de log, les demandes de service ne sont pas nécessairement
émis par le même utilisateur.

Pour un utilisateur authentifié, la chaîne de suivi se compose de la
chaîne, suivie d'une virgule, suivie d'une chaîne associée de manière unique à l'utilisateur
crédits. Ce tracker a une forte probabilité d'être unique et d'avoir un
mappage individuel avec un utilisateur particulier.

Considérez ces entrées de fichier journal (condensées) :

[Mer 12 juillet 15:56:24 2006] [notice] [83963,1067,A] [dacs_acs:"authlib"]
*** Accès accordé à un utilisateur non authentifié (7vJLWzv5) à partir du 10.0.0.124
pour /cgi-bin/dacs/dacs_current_credentials

[Mer 12 juillet 15:56:27 2006] [notice] [83965,1073,A] [dacs_acs:"authlib"]
*** Accès accordé à un utilisateur non authentifié (7vJLWzv5) à partir du 10.0.0.124
pour /cgi-bin/dacs/dacs_authenticate

[Mer 12 juillet 15:56:27 2006] [debug] [83966,172,A] [dacs_authenticate:"authlib"]
Authentification réussie pour HOME:bobo (7vJLWzv5,wA/Pudyp3f0)

[Mer 12 juillet 15:56:30 2006] [notice] [83973,1078,A] [dacs_acs:"authlib"]
*** Accès accordé à DSS::HOME:bobo (7vJLWzv5,wA/Pudyp3f0)
à partir de 10.0.0.124 pour /cgi-bin/dacs/dacs_current_credentials

Dans les deux premiers des messages de journal ci-dessus, le tracker 7vJLWzv5 apparaît, ce qui signifie que
les deux demandes provenaient probablement du même utilisateur (non authentifié). Avec le troisième
message de journal, l'utilisateur a été authentifié et le tracker 7vJLWzv5,wA/Pudyp3f0 est
utilisé. Étant donné que ces trackers partagent tous le même préfixe, les deux premières requêtes
provenait probablement aussi de quelqu'un qui s'est authentifié en tant que DSS::HOME:bobo. La dernière demande,
pour /cgi-bin/dacs/dacs_current_credentials, vient certainement de cet utilisateur. Si ce
l'utilisateur devait se déconnecter puis émettre plus de demandes de service n'importe où dans la fédération
DSS, chaque message de journal contiendrait le tracker 7vJLWzv5.

Sécurité
Il est difficile de bien suivre les demandes des utilisateurs anonymes de manière fiable. UNE
l'approche basée sur les cookies peut faire mieux dans certaines situations, mais a ses propres inconvénients
(comme être totalement inefficace lorsque l'utilisateur a désactivé les cookies).

Suivi Utilisateur Activité
DACS inclut une fonctionnalité, activée en tant qu'option au moment de la construction (voir dacs.installer(7)[48]), selon laquelle
une juridiction peut suivre l'activité de tous ses utilisateurs (c'est-à-dire les utilisateurs qui
authentifier auprès de la juridiction). Chaque événement d'authentification réussi, déconnexion explicite
l'événement et l'événement de demande de service Web soumis par l'utilisateur peuvent être enregistrés au domicile de l'utilisateur
juridiction dans le format défini par dacs_user_info.dtd[49]. Ces informations peuvent être
précieux pour mieux comprendre ce qui se passe dans une fédération,
notamment en aidant à diagnostiquer les problèmes de performances et de sécurité. C'est la base des fonctionnalités
comme les affichages de l'activité récente du compte, et il peut également être utilisé pour créer de nouveaux
fonctionnalités, telles qu'une limite de connexion simultanée ou un composant d'authentification adaptative pour
mettre en œuvre une authentification en couches ou une authentification basée sur les risques.

Pour spécifier où et comment une juridiction d'origine doit conserver ces enregistrements, user_info
le type d'élément doit être défini dans cette juridiction ; s'il n'est pas défini, aucun enregistrement ne sera
écrit à cette juridiction, bien que la juridiction essaiera toujours d'envoyer l'événement
dossiers à d'autres juridictions. Pour un bénéfice maximal, la fonctionnalité doit être activée du tout
juridictions dans une fédération puisque toute activité d'utilisateur dans toute la fédération peut alors
être connecté.

Si une juridiction souhaite surveiller l'activité de ses utilisateurs dans d'autres juridictions, elle
doit permettre à ces juridictions d'invoquer sa dacs_vfs(8)[50] en ajoutant un
règle de contrôle d'accès appropriée.

Sécurité
Il est essentiel qu'une telle règle exige que le dacs_admin()[51] prédicat.

Notes
· Le dacs_admin(8)Les outils [52] fournissent une interface à ces enregistrements. Cela devrait
éventuellement être étendu pour collecter et organiser les dossiers trouvés dans toutes les juridictions
dans une fédération pour faciliter l'analyse. Parce qu'il s'agit de fichiers texte avec un
format relativement simple, les administrateurs ne devraient pas avoir de difficultés à appliquer
outils de traitement de texte courants ou écrivez de courts programmes personnalisés à cette fin.
Commandes analogues à dernier(1)[53] pour qui(1)[54], et sa(8)[55] sont à l'étude.

· Chaque juridiction doit écrire des enregistrements à son propre endroit (c'est-à-dire, les juridictions
ne doit pas partager le même objet VFS pour user_info).

· Cette base de données grandira indéfiniment ; un administrateur est responsable de la rotation
ou en le tronquant. Si les informations de connexion précédentes et actives sont importantes (voir
dacs_current_credentials(8)[56]), élaguer uniquement les enregistrements de requête (c'est-à-dire l'acs
éléments). Une autre méthode acceptable consiste à éliminer (ou archiver) une partie des
enregistrements plus anciens (disons, la moitié) et conserver certains des enregistrements les plus récents.

· Le format des données est sujet à changement.

· Une directive pour activer ou désactiver cette fonctionnalité au moment de l'exécution peut être ajoutée.

· Les événements administratifs internes ne sont pas enregistrés.

· Parce que la déconnexion (via dacs_signout(8)[57]) est facultatif, la fin d'une session
ne peut parfois être déduit ou approximé que de l'expiration des pouvoirs ou
l'heure du dernier événement enregistré.

OPTIONS

DACS les programmes et les services Web obtiennent une grande partie de leurs informations de configuration d'exécution en
lire les fichiers de configuration et examiner les variables d'environnement. Quelques configurations
des informations peuvent être fournies au moment de la compilation. Plusieurs indicateurs de ligne de commande peuvent être utilisés pour
outrepasser le comportement par défaut.

Notes
· Tous options dacs les drapeaux sont traités de gauche à droite et doivent apparaître avant tout
indicateur ou argument spécifique à la commande. Le premier indicateur ou argument qui n'est pas
reconnu comme l'un des options dacs termine la liste.

· Le plus important options dacs sont ceux qui précisent l'emplacement de
fichiers de configuration et identifier la section de juridiction à utiliser dans un
fichier de configuration. Selon le programme et son utilisation, la configuration
l'information peut ne pas être nécessaire, peut être facultative ou peut être requise.

· Au plus un des indicateurs de ligne de commande pour sélectionner une section de juridiction peut être
spécifié. Faire référence à dacs.conf(5)[46] pour plus d'informations sur la
fichier de configuration et traitement de la configuration.

Merci beaucoup DACS Les utilitaires reconnaissent les options standard suivantes, appelées
options dacs:

-c dacs.conf
Cela raconte DACS où il peut trouver un fichier de configuration pour la juridiction sur laquelle
au nom qu'il agit. Si cet argument n'est pas présent, selon la façon dont il a été construit,
DACS peut soit essayer d'utiliser un fichier spécifié au moment de la compilation, soit essayer d'utiliser le
valeur de la variable d'environnement DACS_CONF[58]. Pour plus de détails, reportez-vous à Localisation
dacs.conf et site.conf[59].

-Dprénom=Plus-value
L'effet de ce drapeau est de définir la variable prénom (qui doit être syntaxiquement valide)
dans le DACS espace de noms pour avoir la valeur Plus-value. Toutes les citations autour Plus-value sont conservés,
à condition que la coque ne les ait pas déjà dépouillés. Ce drapeau peut être répété. Ces
les variables peuvent ensuite être testées lors du traitement de la configuration et de la règle
En traitement; par exemple, la valeur d'une directive de configuration peut dépendre de la
valeur d'un options dacs drapeau. Définir un prénom qui correspond à un
options dacs flag n'a d'autre effet que de créer la variable.

Tous options dacs drapeaux (à l'exclusion ceci. UN) sont automatiquement ajoutés au DACS
espace de noms au fur et à mesure qu'ils sont traités. Un drapeau qui est un "singleton" (par exemple, -q) est initialement
attribué une valeur de un et est incrémenté à chaque apparition suivante. Un drapeau de
la forme -drapeau Plus-value équivaut à -D-drapeau=Plus-value. Les drapeaux inutilisés ne sont pas définis ; si -q
n'est pas donné, ${DACS::-q} ne sera pas défini. Pour les drapeaux qui ont des synonymes, un
variable pour chaque synonyme est créée. Si la prénom est utilisé, explicitement ou implicitement,
les valeurs ultérieures remplacent les précédentes.

Par exemple, si le options dacs sont:

-c www.example.com -v --verbose -Dfoo="baz" -ll debug -D-ll=trace

alors les variables seront définies comme suit :

${DACS::-c} est "www.exemple.com"
${DACS::-v} vaut "2"
${DACS::--verbose} vaut "2"
${DACS::foo} est "\"baz\""
${DACS::-ll} est "trace"

Le niveau de débogage sera debug et non trace.

--dumpenv
Imprimez toutes les variables d'environnement sur stdout, puis quittez immédiatement.

--enable-dump
Par défaut, DACS les services Web et la plupart des commandes désactivent la génération de vidage de mémoire en tant que
précaution de sécurité. Parce qu'un core dump peut être utile lors du débogage, cet indicateur
permet de le créer. Comme les programmes autorisés à produire un vidage de mémoire doivent
changer pour le DACS_HOME répertoire, les vidages de mémoire y seront écrits. Utiliser ce drapeau
avec soin.

-format fmt
Le format de sortie est défini sur fmt, qui est l'un des mots-clés suivants (cas
insensible) : file, html, json, php, plain, text, xml, xmldtd, xmlsimple ou
xmlschema. Tous les formats de sortie ne sont pas pris en charge par tous les programmes. Ce drapeau remplace
tout Format[60] argument à un service Web, qui à son tour remplace la valeur par défaut d'un programme
format. Le format par défaut dépend du programme particulier et de la manière dont il est invoqué.
Pour plus d'informations, reportez-vous au la description of le Format argumentation[60].

-ll niveau de journalisation
Le niveau de journalisation est défini sur niveau de journalisation, qui est l'un des mots-clés reconnus par le
LOG_FILTER[61] directive.

--Licence
Imprimer la licence pour DACS vers stdout, puis quittez immédiatement.

-q
Soyez silencieux. Cela équivaut à définir le niveau de journalisation pour avertir.

-sc site.conf
Cela raconte DACS qu'il peut trouver un fichier de configuration pour la juridiction sur laquelle
au nom qu'il agit. Si cet argument n'est pas présent, selon la façon dont il a été construit,
DACS peut soit essayer d'utiliser un fichier spécifié au moment de la compilation, soit essayer d'utiliser le
valeur de la variable d'environnement DACS_CONF[58]. Pour plus de détails, reportez-vous à Localisation
dacs.conf et site.conf[59].

--std
Cela marque la fin des arguments communs. Le prochain argument de la ligne de commande, le cas échéant, est
spécifique au programme.

-t
Émettre des informations de traçage. Cela équivaut à définir le niveau de journalisation sur trace.
(Regarde aussi debug_dacs[62].)

-u config-uri
Cela indique DACS à utiliser config-uri pour sélectionner la section de juridiction à utiliser dans le
fichier de configuration. Pour plus de détails, reportez-vous à Votre Jurisdiction Blog[63].

-uj nom-juridiction
Cela indique DACS utiliser le nom de la juridiction nom-juridiction pour sélectionner le
section juridiction à utiliser dans le fichier de configuration. Pour plus de détails, reportez-vous à Votre
Jurisdiction Blog[63].

A
Cela indique DACS de ne pas traiter site.conf ou dacs.conf. Cela ne peut être utilisé qu'avec
un petit nombre de commandes, telles que dacsacl(1)[64] et client ssl(1)[4].

-up nom-juridiction
PAS MIS EN ŒUVRE. Cela indique DACS utiliser le nom de la juridiction nom-juridiction à
sélectionnez la section de juridiction à utiliser dans le fichier de configuration et lui indique que le
le serveur Web agit comme un proxy direct ; C'est, nom-juridiction ne collecte
nécessairement "posséder" l'URL demandée. Pour plus de détails, reportez-vous à Votre Jurisdiction
Blog[63].

-nous
Cela indique DACS d'utiliser la section juridiction unique qui apparaît dans le
fichier de configuration. C'est-à-dire que le fichier de configuration doit contenir exactement un
section de compétence et c'est celle qui devrait être utilisée. Pour plus de détails, reportez-vous à
Votre Jurisdiction Blog[63].

-v
--verbeux
Soyez plus détaillé par rapport au niveau de journalisation actuel. Ce drapeau peut être répété.

--version
Imprimez immédiatement les informations de version sur stderr, puis quittez. Si -v est apparu plus tôt
sur la ligne de commande, imprimez également les informations de version pour chaque DACS fichier de code source dans
ce programme.

Notes
Les informations de version complètes sont disponibles uniquement pour les programmes liés de manière statique.
Regarde aussi version dacs(1)[65] et dacs_version(8)[66].

Conseil
Si aucun indicateur de ligne de commande n'est donné pour spécifier la section de juridiction, la valeur de
variable d'environnement JURIDICTION_DEFAUT sera utilisé comme s'il était donné avec le -uj drapeau.
Cela peut être particulièrement utile lorsqu'un hôte n'a qu'une seule juridiction configurée
parce qu'il n'est pas nécessaire de toujours spécifier la juridiction pour DACS les commandes.

ENVIRONNEMENT

SERVER_NAME, SERVER_PORT, REQUEST_URI
Peut être utilisé pour déterminer la juridiction applicable.

Utiliser des dacs en ligne à l'aide des services onworks.net