7. SSO et contrôle d'accès
Authentification
• Framework d'authentification extensible basé sur JAAS
• Support de multiples modules d'authentifications
> LDAP, RADIUS, Certificate, SafeWord, RSA SecureID, Unix,
Windows NT, WindowsDesktopSSO (Kerberos), Anonymous,
Membership (self-enrollment)
> SPI pour intégrer/développer des modules d'authentifications
spécifiques ``
• Authentification multi-facteurs (Chaînage)
• Multi-niveaux et Multi-schémas
• Authentification par ressource
> Utilisateur, realm, service, module, niveau
• Notion de royaumes
8. SSO et contrôle d'accès
Autorisation
• Policy = Règles + Sujets + Conditions +
Response Provider
> Règle – La ressource à protéger (e.g. URL)
> Sujet – Celui qui est autorisé à accéder à la
ressource (User/Role/Group etc.)
> Condition – Contraintes supplémentaires (IP
Address mask, authN level/scheme, time/day
etc.)
> Response Provider – Données additionnelles à
envoyer à la ressource.
9. Installation et configuration
• Support d'un éventail plus important de systèmes
d'exploitation (Solaris, Linux, Windows, AIX et Ubuntu)
• Plus de conteneurs web (Sun WS, Sun AS, Weblogic,
WebSphere, Oracle Application Server, Jboss, Tomcat,
Geronimo)
• Déploiement avec un seul war
• Plusieurs configurations pré-définies (Wizard)
• Processus de fédération simplifié
> Echange des métadonnées (fichiers/réseau)
> Test SSO, SLO
10. Contrôle d'accès : les nouveautés
• Référentiel de configuration embarqué (basé sur
OpenDS)
• Plus de référentiels utilisateurs supportés (Sun DS,
AD, IBM DS, LDAP v3)
• Gestion des configurations centralisée
• Gestion des agents centralisée
• Nouvelle interface CLI (famadm)
22. OpenSSO : Fédération
• Fedlet : Création d'un modèle de service provider SAML2
configuré et intégré en quelques minutes
• Hub de fédération multi-protocoles : Intégration d'un SP
indépendamment de son quot;langage de fédérationquot;
• Proxy de fédération virtuel : Utilisation des protocoles de
fédération pour le transport sécurisé d'attributs d'applications
legacy
• Support des standards majeurs tels que SAML, WS-
Federation, Liberty ID-FF, WS-Trust, WS-Security et WS-
Policy
• Consomme et traduit les jetons des solutions WAM les plus
répandues
25. Sécurité Web Services
Besoins
Identification de l'utilisateur
Préserver l'identité
Préserver l'intégrité et l'anonymat
Utilisation des technologies existantes
Audit
26. Sécurité Web Services
Problèmes
La sécurité du protocole est
essentielle mais insuffisante
Seulement du point à point.
Pas de non-répudiation
Pas de sécurité hors protocole
Pas d'élément du message signé &
encrypté
31. Identity Services et sécurité Web
Services
• Identity Services
• Security Token Service (STS)
• Sécurité Web Services (API, Framework, Plug-ins)
32. Sécurité web services : Trois
modèles
• JSR 196 plug-ins
> Intégration en tant que filtre sur les serveurs
d'applications
• Identity Services
> Interfaces wsdl/REST pour
– Authentification
– Autorisation
– Attributs
– Logging
• Framework et standards
> Liberty Alliance (ID-WSF), WS-*
33. OpenSSO : Agents Web Services
(JSR 196)
• Problème:
> Comment mettre en place la sécurisation de web WSS Agent
services dans des conteneurs différents sans OpenSSO clientsdk 4
modifier l'application ? Web Service
Provider
• Le processus
SOAP 3 5
> Fournit un agent qui est déployé sur le conteneur (WSS)
pour consommer, valider et transformer les jetons 2 Serveur
de sécurité. WSS Agent OpenSSO
> Abstraction de la sécurité par rapport à l'application OpenSSO clientsdk
(orthogonalité).
> Un agent WSS permet de standardiser la sécurité Web Service
indépendemment du conteneur (e.g. Sun, IBM, Client
BEA etc.)
– Implémenter une extension d'authentification 1 Requête/Réponse
intégrée au conteneur (JSR 196)
– Sécurisation des requêtes SOAP et validation des
réponses par le WSC.
– Validation des requêtes SOAP et sécurisation des
réponses par le WSP.
34. Secure Token Service (STS)
• Problème :
> Comment un Web service vérifie l'identité présentée
par une application cliente ?
• Le processus Web Service
Provider
> Un web service client nécessite un jeton authentifié Issue Token
pour accéder à un web service serveur. SOAP 3 (WS-Trust)
(WSS)
> Le STS vérifie l'identité présentée par le client et 2
génère un jeton de sécurité qui prouve que le client a
été authentifié par le STS.
> Le client présente le jeton WS-I BSP (User Name,
X.509, SAML etc.) au Web service serveur. Web Service Security Token
> Le Web service serveur vérifie que le jeton a été Client Service
généré par un STS de confiance, qui prouve que le
client a été authentifié par le STS. 1 Requête/Réponse
35. Identity Services
• Permettre aux développeurs
d'invoquer les services
d'OpenSSO.
• Disponible sous la forme d'un
ensemble de Web Services
accessibles via SOAP et REST.
`
• Solution sans agent qui ne
nécessite pas le déploiement
d'un agent ou d'un proxy pour
protéger la ressource.
• Supporte les IDE courants.
36. Identity Services disponibles
Authentification Autorisation
Vérification des credentials Permission d'accès à une
authenticate (username, ressource pour un utilisateur
password, uri) => Token authentifié.
authorize (Resource, Action,
Token) => boolean
Attributs Audit
Sélection d'attributs d'un Capacité d'auditer et
utilisateur authentifié. d'enregistrer une opération.
attributes(List attrNames, log (AppToken, Token,
Token) => UserDetails Logname, Message)