« POSTFIX - Formation Postfix - Configuration Cyrus » et « FEDERATION - Shibboleth » : différence entre les pages

De PedroWiki
(Différence entre les pages)
Aller à la navigationAller à la recherche
 
Nouvelle page : = Introduction = Fédération d'identité: (A REDIGER, cf notes en fin de TP de formation) Sibboleth, définition: (A REDIGER) = Structure = 2 parties principales: l'IdP et le SP...
 
Ligne 1 : Ligne 1 :
= /etc/cyrus.conf =
= Introduction =


# Debian defaults for Cyrus IMAP server/cluster implementation
Fédération d'identité: (A REDIGER, cf notes en fin de TP de formation)
# see cyrus.conf(5) for more information
#
# All the tcp services are tcpd-wrapped. see hosts_access(5)
# $Id: cyrus.conf 567 2006-08-14 18:19:32Z sven $
START {
        # do not delete this entry!
        recover        cmd="/usr/sbin/ctl_cyrusdb -r"
        # this is only necessary if idlemethod is set to "idled" in imapd.conf
        #idled          cmd="idled"
        # this is useful on backend nodes of a Murder cluster
        # it causes the backend to syncronize its mailbox list with
        # the mupdate master upon startup
        #mupdatepush  cmd="/usr/sbin/ctl_mboxlist -m"
        # this is recommended if using duplicate delivery suppression
        delprune        cmd="/usr/sbin/cyr_expire -E 3"
        # this is recommended if caching TLS sessions
        tlsprune        cmd="/usr/sbin/tls_prune"
}
# UNIX sockets start with a slash and are absolute paths
# you can use a maxchild=# to limit the maximum number of forks of a service
# you can use babysit=true and maxforkrate=# to keep tight tabs on the service
# most services also accept -U (limit number of reuses) and -T (timeout)
SERVICES {
        # --- Normal cyrus spool, or Murder backends ---
        # add or remove based on preferences
        imap            cmd="imapd -U 30" listen="imap" prefork=0 maxchild=100
        #imaps          cmd="imapd -s -U 30" listen="imaps" prefork=0 maxchild=100
        pop3            cmd="pop3d -U 30" listen="pop3" prefork=0 maxchild=50
        #pop3s          cmd="pop3d -s -U 30" listen="pop3s" prefork=0 maxchild=50
        nntp            cmd="nntpd -U 30" listen="nntp" prefork=0 maxchild=100
        #nntps          cmd="nntpd -s -U 30" listen="nntps" prefork=0 maxchild=100
        # At least one form of LMTP is required for delivery
        # (you must keep the Unix socket name in sync with imap.conf)
        #lmtp          cmd="lmtpd" listen="localhost:lmtp" prefork=0 maxchild=20
        '''lmtpunix        cmd="lmtpd" listen="/var/run/cyrus/socket/lmtp" prefork=0 maxchild=20'''
        #lmtpunix      cmd="lmtpd" listen="/var/spool/postfix/private/lmtp" prefork=0 maxchild=20
        # ----------------------------------------------
        # useful if you need to give users remote access to sieve
        # by default, we limit this to localhost in Debian
        sieve          cmd="timsieved" listen="localhost:sieve" prefork=0 maxchild=100
        # this one is needed for the notification services
        notify          cmd="notifyd" listen="/var/run/cyrus/socket/notify" proto="udp" prefork=1
        # --- Murder frontends -------------------------
        # enable these and disable the matching services above,
        # except for sieve (which deals automatically with Murder)
        # mupdate database service - must prefork at least 1
        # (mupdate slaves)
        #mupdate      cmd="mupdate" listen=3905 prefork=1
        # (mupdate master, only one in the entire cluster)
        #mupdate      cmd="mupdate -m" listen=3905 prefork=1
        # proxies that will connect to the backends
        #imap          cmd="proxyd" listen="imap" prefork=0 maxchild=100
        #imaps          cmd="proxyd -s" listen="imaps" prefork=0 maxchild=100
        #pop3          cmd="pop3proxyd" listen="pop3" prefork=0 maxchild=50
        #pop3s          cmd="pop3proxyd -s" listen="pop3s" prefork=0 maxchild=50
        #lmtp          cmd="lmtpproxyd" listen="lmtp" prefork=1 maxchild=20
        # ----------------------------------------------
}
EVENTS {
        # this is required
        checkpoint      cmd="/usr/sbin/ctl_cyrusdb -c" period=30
        # this is only necessary if using duplicate delivery suppression
        delprune        cmd="/usr/sbin/cyr_expire -E 3" at=0401
        # this is only necessary if caching TLS sessions
        tlsprune        cmd="/usr/sbin/tls_prune" at=0401
        # indexing of mailboxs for server side fulltext searches
        # reindex changed mailboxes (fulltext) approximately every other hour
        #squatter_1    cmd="/usr/bin/nice -n 19 /usr/sbin/squatter -s" period=120
        # reindex all mailboxes (fulltext) daily
        #squatter_a    cmd="/usr/sbin/squatter" at=0517
}


[[Category:Configuration]]
Sibboleth, définition: (A REDIGER)
[[Category:Cyrus]]
 
[[Category:Postfix]]
= Structure =
 
2 parties principales: l'IdP et le SP.
 
== Fournisseur d'Identité: l'IdP ==
 
Un IdP pour chaque stucture participant à la fédération.
 
L'IdP s'appuie sur le système d'authentification de la structure (par exemple SSO CAS).
 
Il transmet aux SP une validation du login, ainsi que potentiellement des attributs.
 
== Fournisseur de service: le SP ==
 
Un SP pour chaque service utilisant l'authentification Shibboleth (Possibilité d'utiliser un "proxy", 1 SP frontal pour plusieurs services sous-jacents.
 
Le SP est un module pluggable dans Apache ou IIS, et qui permet par de la configuration côté serveur de protéger par Shibboleth des services web.
 
= Remarques =
 
* L'utilisation du SP pour l'authentification sur un service web est à développer du coté applicatif (service web).
* L'utilisation de l'authentification Shibboleth occasionne l'ouverture de plusieurs sessions:
** 1 session du côté SP
** 1 session du côté IdP
** 1 session du côté système d'authentification sous-jacent à l'IdP (CAS par exemple).
** éventuellement 1 session "applicative" du côté service web ayant nécessité l'authentification.
* SLO: Single LOgout. Mécanisme permettant de clore '''toutes''' les sessions ouvertes, annoncé avec la version 2.x de l'IdP mais non encore développée à ce jour. Principe: le logout de l'application, par l'appel à une URL pointant sur le SP, permettrais de déclencher une série de demandes de fermetures vers tous les acteurs cités plus haut. '''ATTENTION''' à l'heure actuelle, uniquement fermeture de session du côté SP.
 
= Liens utiles =
 
[http://www.cru.fr/faq/federation/index Les FAQ "Fédération d'identité" du CRU]
 
[[Category:Securite]]
[[Category:Shibboleth]]
[[Category:A MODIFIER]]

Version du 30 octobre 2008 à 14:28

Introduction

Fédération d'identité: (A REDIGER, cf notes en fin de TP de formation)

Sibboleth, définition: (A REDIGER)

Structure

2 parties principales: l'IdP et le SP.

Fournisseur d'Identité: l'IdP

Un IdP pour chaque stucture participant à la fédération.

L'IdP s'appuie sur le système d'authentification de la structure (par exemple SSO CAS).

Il transmet aux SP une validation du login, ainsi que potentiellement des attributs.

Fournisseur de service: le SP

Un SP pour chaque service utilisant l'authentification Shibboleth (Possibilité d'utiliser un "proxy", 1 SP frontal pour plusieurs services sous-jacents.

Le SP est un module pluggable dans Apache ou IIS, et qui permet par de la configuration côté serveur de protéger par Shibboleth des services web.

Remarques

  • L'utilisation du SP pour l'authentification sur un service web est à développer du coté applicatif (service web).
  • L'utilisation de l'authentification Shibboleth occasionne l'ouverture de plusieurs sessions:
    • 1 session du côté SP
    • 1 session du côté IdP
    • 1 session du côté système d'authentification sous-jacent à l'IdP (CAS par exemple).
    • éventuellement 1 session "applicative" du côté service web ayant nécessité l'authentification.
  • SLO: Single LOgout. Mécanisme permettant de clore toutes les sessions ouvertes, annoncé avec la version 2.x de l'IdP mais non encore développée à ce jour. Principe: le logout de l'application, par l'appel à une URL pointant sur le SP, permettrais de déclencher une série de demandes de fermetures vers tous les acteurs cités plus haut. ATTENTION à l'heure actuelle, uniquement fermeture de session du côté SP.

Liens utiles

Les FAQ "Fédération d'identité" du CRU

Récupérée de « http://wiki.pedrono.fr/index.php?title=POSTFIX_-_Formation_Postfix_-_Configuration_Cyrus&oldid=149 »