For z/OS platforms

Accès aux ressources de sécurité z/OS à l'aide de WZSSAD

L'acronyme WZSSAD (z/OS System Security Access Domain) désigne les permissions octroyées au serveur Liberty. Ces permissions (ou droits) contrôlent quels domaines d'application et profils de ressource SAF le serveur peut interroger lorsqu'il doit authentifier et autoriser des utilisateurs.

Par exemple, si vous voulez configurer deux instances de serveur Liberty, une pour la production et l'autre pour le test, et que vous voulez que votre accès en fonction du rôle diffère pour la production et le test, vous pouvez configurer deux domaines d'accès de sécurité du système différents.

Le serveur Liberty est un programme non autorisé qui peut être configuré et exécuté par des utilisateurs qui ne sont pas des administrateurs ou qui ne sont pas des utilisateurs privilégiés. Par conséquent, il est important pour l'intégrité et la sécurité du système que l'utilisateur ne puisse pas profiter du serveur pour exécuter des opérations pour lesquelles il ne dispose pas explicitement des droits.

Remarque : Le domaine WZSSAD est en vigueur uniquement lorsque le serveur utilise des services SAF autorisés pour l'authentification et l'autorisation des utilisateurs. Cela signifie que le processus ange est lancé et que le serveur a reçu le droit d'utiliser les routines de service autorisé SAFCRED.
Trois opérations SAF sont protégées par WZSSAD :
  • Authentification d'un utilisateur
  • Autorisation d'un sujet en tant que rôle Java™ EE
  • Autorisation d'un sujet pour d'autres ressources SAF
Par défaut, WZSSAD n'est pas configuré, ce qui signifie que le serveur ne dispose pas des droits permettant d'authentifier ou d'autoriser qui que ce soit. Par exemple, le serveur Liberty ne peut pas utiliser les services SAF autorisés pour l'authentification ou l'autorisation tant qu'un administrateur ne lui a pas accordé le droit d'exécuter certaines des opérations ou toutes les opérations.

Authentification d'un utilisateur

Le serveur authentifie des utilisateurs auprès d'un domaine SAF particulier qui est configuré via la définition d'une ressource appelée APPLID dans la classe APPL. Pour qu'un utilisateur soit authentifié auprès du domaine, il doit disposer de l'accès en lecture (READ) à la ressource APPLID de la classe APPL. De plus, à chaque fois que la classe APPL est active, l'ID utilisateur non authentifié (WSGUEST par défaut) requiert également l'accès READ à la ressource APPLID dans la classe APPL.

Le nom de ressource APPLID utilisé par le serveur est spécifié par l'attribut profilePrefix dans l'élément de configuration <safCredentials>. Si vous ne spécifiez pas cet élément, la valeur par défaut de profilePrefix BBGZDFLT est utilisée.

L'exemple suivant illustre la configuration d'un élément profilePrefix BBGZDFLT dans le fichier server.xml :
<safCredentials profilePrefix="BBGZDFLT"/>
L'exemple suivant explique comment utiliser des commandes RACF pour configurer APPLID en tant que BBGZDFLT :
// Define the BBGZDFLT APPLID to RACF.
RDEFINE APPL BBGZDFLT UACC(NONE)

// Activate the APPL class. 
//If not active, the domain is not restricted, which means anyone can authenticate to it.
SETROPTS CLASSACT(APPL)

//All users to be authenticated by the server must have READ access to the APPLID in the APPL class:
PERMIT BBGZDFLT CLASS(APPL) ACCESS(READ) ID(UserID)

//The unauthenticated user ID requires READ access to the APPLID in the APPL class:
PERMIT BBGZDFLT CLASS(APPL) ACCESS(READ) ID(WSGUEST)
De plus, le serveur doit disposer du droit approprié dans WZSSAD pour pouvoir effectuer des appels d'authentification dans le domaine APPLID donné. Ainsi, un utilisateur non autorisé ne pourra pas profiter du fait que le serveur utilise des services SAF autorisés pour obtenir des informations sur les ressources APPLID pouvant ou non être authentifiées. Pour autoriser le serveur à procéder à l'authentification dans un domaine APPLID spécifique, un accès en lecture (READ) doit être accordé à l'ID de tâche démarrée du serveur Liberty sur le profil BBG.SECPFX.<APPLID> dans la classe SERVER :
RDEFINE SERVER BBG.SECPFX.BBGZDFLT UACC(NONE)
PERMIT BBG.SECPFX.BBGZDFLT CLASS(SERVER) ACCESS(READ) ID(serverUserId)

Autorisation d'un sujet en tant que rôle Java EE

Le serveur autorise un sujet par rapport au nom de rôle de sécurité d'une application Java EE en vérifiant si le sujet est autorisé pour un profil de ressource SAF défini dans la classe EJBROLE. Le nom du profil de ressource SAF est déterminé, d'après le nom de rôle de l'application, par le mappeur de rôles SAF. Le mappeur de rôles SAF génère un nom de profil SAF pour un nom de rôle d'application et un nom de ressource application donnés. Par défaut, il génère le nom de profil SAF selon le modèle {préfixeProfil}.{ressource}.{rôle}. Exemple :
profilePrefix="BBGZDFLT"

Application resource name = "MYAPP"

Application role name = "ADMIN"

Mapped profile name = "BBGZDFLT.MYAPP.ADMIN"

Pour plus d'informations, voir Liberty : Contrôle de la manière dont les rôles sont mappés aux profils SAF

Le domaine WZSSAD détermine avec quels profils SAF, dans la classe EJBROLE, le serveur peut exercer la vérification d'autorisation. On évite ainsi qu'un utilisateur non autorisé profite du fait que le serveur utilise des services SAF autorisés pour découvrir les profils EJBROLE qui peuvent être autorisés et ceux qui ne peuvent pas l'être. Le serveur doit recevoir la permission d'exécuter des vérifications d'autorisation avec le HLQ (qualificatif de haut niveau) du nom de profil EJBROLE. Le HLQ du nom de profil est le premier segment à gauche du point. Exemple :
EJBROLE profile name = "BBGZDFLT.ADMIN" 
HLQ = "BBGZDFLT"
Pour autoriser le serveur à effectuer des vérifications d'autorisation avec le HLQ du profil, l'ID utilisateur associé au processus serveur doit disposer d'un accès en lecture (READ) au profil BBG.SECPFX.<HLQ> dans la classe SERVER :
RDEFINE SERVER BBG.SECPFX.BBGZDFLT UACC(NONE)
PERMIT BBG.SECPFX.BBGZDFLT CLASS(SERVER) ACCESS(READ) ID(serverUserId)
Dans cet exemple, comme le mappeur de rôles SAF utilise la valeur de l'attribut profilePrefix comme HLQ dans le nom du profil SAF qu'il génère, le même profil, nommé BBG.SECPFX.BBGZDFLT, réglemente à la fois le droit d'exercer des vérifications d'authentification avec APPLID et le droit d'exercer des vérifications d'autorisation avec le profil EJBROLE.

Autorisation d'un sujet pour d'autres ressources SAF

Les applications Java EE peuvent procéder à des vérifications de contrôle d'accès en fonction de classes SAF autres que EJBROLE. Le domaine WZSSAD détermine avec quelles classes SAF autres que EJBROLE le serveur peut exercer la vérification d'autorisation. On évite ainsi que des utilisateurs ou des applications non autorisés profitent du fait que le serveur utilise des services SAF autorisés pour découvrir avec quels profils de ressource, dans les classes SAF autres que EJBROLE, ils peuvent être autorisés.

Pour donner au serveur le droit d'effectuer des vérifications d'autorisation avec une classe SAF autre que EJBROLE, l'ID utilisateur associé au processus du serveur doit bénéficier d'un accès READ au profil BBG.SECCLASS.<SAF-CLASS> dans la classe SERVER. Voici, par exemple, la définition à utiliser pour que le serveur puisse effectuer des vérifications d'autorisation avec un profil dans la classe FACILITY :
RDEFINE SERVER BBG.SECCLASS.FACILITY UACC(NONE)
PERMIT BBG.SECCLASS.FACILITY CLASS(SERVER) ACCESS(READ) ID(serverUserId)
Remarque : Les profils de ressource dans une classe SAF autre que EJBROLE sont tous utilisables par le serveur dès lors que celui-ci reçoit le droit d'effectuer des vérifications d'autorisation avec cette classe.

Icône indiquant le type de rubrique Rubrique de référence

Nom du fichier : rwlp_WZSSAD_zos.html