Service d'accréditation
Le service de jeton de sécurité fourni par WebSphere Application Server s'appelle le service d'accréditation. Le service d'accréditation WebSphere Application Server utilise les mécanismes de messagerie sécurisés de Web Services Trust (WS-Trust) pour définir d'autres extensions pour l'émission, l'échange et la validation des jetons de sécurité.
Web Services Trust (WS-Trust) est une norme OASIS qui permet l'interopérabilité de jeton de sécurité en définissant un protocole de demande/réponse. Ce protocole permet aux acteurs SOAP, tels qu'un client de services Web, de demander à une autorité habilitée qu'un jeton de sécurité particulier soit échangé contre à un autre.
WebSphere Application Server ne fournit pas un service complet de jeton de sécurité qui implémente tout le contenu de la spécification du projet WS-Trust. Le support WebSphere Application Server de WS-Trust se concentre sur l'établissement d'un jeton de contexte de sécurité pour sécuriser les conversations. WebSphere Application Server prend en charge de nombreuses fonctions de sécurité décrites dans la version 1.3 de la norme WS-Trust OASIS du 19 mars 2007.
Client WS-Trust tiers
WebSphere Application Server ne fournit pas une implémentation du client WS-Trust. Vous pouvez utiliser un client tiers WS-Trust, mais dans ce cas, WebSphere Application Server ne prend pas en charge un client tiers d'accréditation. Un client sécurisé peut faciliter la génération de ces messages SOAP et le traitement de la réponse, mais il n'est pas obligatoire.
WebSphere Application Server se concentre sur l'émission, le renouvellement et l'annulation du jeton de contexte de sécurité pour sécuriser les conversations des services Web (WS-SecureConversation).
La spécification WS-Trust doit être respectée pour les demandes du service d'accréditation. Elle inclut l'utilisation d'en-têtes Web Services Addressing (WS-Addressing). Les en-têtes WS-Addressing sont définis dans les spécifications du mois d'août 2004 ou du mois d'août 2005. Conformément à la spécification, le corps SOAP doit comporter un seul élément RequestSecurityToken (RST). Cet élément peut contenir des sous-éléments, comme défini dans les spécifications WS-Trust et WS-SecureConversation.
Vous pouvez sécuriser les messages SOAP WS-Trust à l'aide de la règle d'amorce définie dans l'ensemble de règles. La stratégie de sécurité d'amorce est appelée dans le processus d'un initiateur qui établit une communication avec un service d'application. Les demandes initiales destinées aux services autres que le service d'application sont sécurisées à l'aide de la règle d'amorce. Ces demandes initiales impliquent généralement une ou plusieurs demandes à un service de jeton de sécurité (STS), tel que le service d'accréditation WebSphere Application Server. A titre d'exemple de demande, on peut citer l'acquisition d'un jeton de contexte de sécurité nécessaire pour WS-SecureConversation. Un initiateur est le rôle qui déclenche la demande d'origine et, dans la plupart des cas, il s'agit du client. L'ensemble de règles d'amorce du client doit correspondre aux ensembles de règles d'émission et de renouvellement du service d'accréditation pour le noeud final. Les ensembles de règles d'annulation et de validation du service d'accréditation pour le noeud final doivent correspondre à l'ensemble de règles d'application du client.
WebSphere Application Server fournit deux méthodes pour sécuriser les messages SOAP destinés au service d'accréditation. La première consiste à utiliser la règle d'amorce qui est définie dans l'ensemble de règles. La seconde méthode consiste à utiliser l'API Web Services Security (API XSS). Votre application utilise l'API WSS pour acquérir le jeton de contexte de sécurité pour la conversation sécurisée WS par programmation basée sur une API.
Pour la conversation sécurisée, une demande du client adressée à un service de noeud final est interrompue lors de la génération et du traitement d'un nouvelle (seconde) demande par le service d'accréditation. Le jeton de contexte de sécurité renvoyé avec la seconde demande sert à dériver des clés qui sécurisent les communications avec le service.
Fonctions évoluées du service d'accréditation
La liste suivante énumère les fonctions WS-Trust prises en charge dans WebSphere Application Server. Cette liste n'est pas exhaustive ; elle concerne uniquement sur les fonctions évoluées.
- Le composant de service d'accréditation est incorporé et disponible dans chaque WebSphere Application Server qui traite les messages du protocole WS-Trust.
- La communication est réalisée via RequestSecurityToken (RST),
RequestSecurityTokenCollection (RSTC), RequestSecurityTokenResponse (RSTR) et RequestSecurityTokenResponseCollection (RSTRC). Remarque : Une demande RST peut être adressée à un service de jeton de sécurité externe (service d'accréditation). Toutefois, la restriction impose au service d'accréditation WebSphere Application Server de fournir le jeton de contexte de sécurité qui est, de fait, nécessaire pour WS-SecureConversation.
- Une stratégie de sécurité pour chacune des opérations WS-Trust (émission, annulation, validation et renouvellement).
- Le fournisseur de jeton de contexte de sécurité pré-configuré qui émet des jetons pour une URL spécifique.
- La spécification des paramètres de jeton d'un fournisseur de jeton (par exemple, délai d'expiration).
- Un jeton de contexte de sécurité pour WS-SecureConversation.
- Prise en charge de la mise en mémoire cache pour le jeton de contexte de sécurité dans les environnements à clusters et sans clusters. WebSphere Application Server émet des jetons de sécurité lorsque cela est nécessaire si les demandes correspondent aux règles de sécurité. Toutefois, WS-SecureConversation fourni par WebSphere Application Server traite uniquement les jetons de contexte de sécurité émis par WebSphere Application Server.
- Notez que le service d'accréditation WebSphere Application Server prend en charge uniquement le jeton de contexte de sécurité.
- Le service d'accréditation prend en charge la spécification Submission (2004/08) et la spécification définitive (2005/08) de WS-Addressing.
- Le service d'accréditation se sert d'un ensemble de règles par défaut nommé TrustServiceSecurityDefault : il inclut WS-Security et WS-Addressing et fournit une sécurité par défaut pour les opérations d'émission et de renouvellement.
- Le service d'accréditation utilise un second ensemble de règles par défaut nommé TrustServiceSymmetricDefault : il inclut WS-Security et WS-Addressing et fournit une sécurité par défaut pour les opérations d'annulation et de validation.
Fonctions de service d'accréditation non prises en charge
- Aucun protocole de négociation et d'échange n'est pris en charge.
- Aucun autre type de jeton n'est actuellement pris en charge directement.
- Aucune spécification Trust10 de WS-SecurityPolicySet n'est prise en charge.
- Aucun RequestSecurityTokenResponse (RSTR) non sollicité n'est pris en charge.
- Une demande de RST (Request Security Token) ne peut pas être émise à un service de jeton de sécurité (STS) externe pour établir une conversation sécurisée ; seul le service d'accréditation incorporé est actuellement pris en charge.
- Les demandes de règles contenues dans le RST ne sont pas honorées.
- La fonction de modification de jeton (opération de modification) n'est pas prise en charge.
- Un noeud final externe dédié permettant d'accéder au service de jeton n'est pas pris en charge ; seul le service d'accréditation incorporé est actuellement pris en charge.
- Le service d'accréditation ne prend pas en charge l'élément Entropy qui contient un EncryptedKey.
- La délégation et l'acheminement ne sont pas pris en charge.
- L'élément OnBehalfOf n'est pas pris en charge.
- La liaison KET (Key Exchange Token) n'est pas prise en charge.
Opérations du service d'accréditation
WebSphere Application Server permet spécifiquement au service d'accréditation d'émettre, pour le compte du noeud final, un jeton de contexte de sécurité pour WS-SecureConversation. Le support d'émission de jeton est actuellement limité au jeton de contexte de sécurité. Il existe également la fonction de gestion de règles sécurisées qui sert à définir une règle permettant au service d'accréditation d'émettre, d'annuler, de valider ou de renouveler des jetons.
- http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Issue
- http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Cancel
- http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Validate
- http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Renew
- http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/SCT
- http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/SCT/Cancel
- http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/SCT/Renew
Un RST entrant pour l'opération d'émission de jeton de contexte de sécurité doit contenir un élément Entropy. Ce dernier doit contenir un BinarySecret. Le service d'accréditation ne prend pas en charge l'élément Entropy qui contient un EncryptedKey.
Il est à noter que le service d'accréditation ne prend pas en charge les actions RSTR non sollicitées. En outre, il n'est pas possible de modifier un jeton WebSphere Application Server. Reportez-vous également à la section Fonctions de service d'accréditation non prises en charge.
Fichiers liés aux ensembles de règles sécurisées
L'ensemble de règles de service d'accréditation par défaut des opérations d'émission et de renouvellement est TrustServiceSecurityDefault. Vous pouvez configurer la liaison et l'ensemble de règles correspondants pour chaque URL de noeud final de service.