Gestion des Autorisations - users.b-rail.beusers.b-rail.be/portal_doc/prod/A966C/F/Authorisations - Manager... · 3.2 Gestion d'application ... Gestion des Autorisations AUTORISATION

Gestion des Autorisations

Manuel de la Gestion des Autorisations dans le Portail

Références

Auteur : Jessie Meier Document : Authorisations - Manager Manual v3.2 F.doc Version : 3.2.0 Date : 23/01/08

Template : Manual.dot

Versions

Version Date Explication 1.x 19/03/04 Version provisoire, première mise à disposition hors ICT. 2.x 23/03/04 Adaptations groupe d'objets, traduction en 4 langues, fonction de préférence, etc.

Adaptation "remplacement de Personne par Utilisateur", demandes de relation, etc. 2.2 21/12/04 Portal Release production december ‘04 (excl. Role Type) 2.3 04/04/05 Portal release avril acceptation / mai production ’05 (valeur par défaut) 2.4 01/09/05 Introduction de rôle avec attribution implicite 2.5 24/04/06 Introduction de la gestion de relation 2.6 31/07/06 Gestion de relation : deuxième partie 2.7 12/10/06 Nouvelles fonctions de copie, gestion de relation, recherche d’une valeur 3.0 27/10/06 Abolition des fonctions publiques, fonction batch ‘Restriction – valuer

automatique’ 3.1 17/04/07 Composition du menu 3.2 13/11/07 Explication sur le rafraîchissement des données d’autorisations (3.3)


Table des matières

1. Concepts ..............................................................................................................................1 1.1 Application ...............................................................................................................1 1.2 Objet .........................................................................................................................3 1.3 Groupe d'objets.........................................................................................................4 1.4 Fonction....................................................................................................................4 1.5 Utilisateur .................................................................................................................7 1.6 Rôle ........................................................................................................................10 1.7 Attribution ..............................................................................................................12 1.8 Type de rôle............................................................................................................13 1.9 Accès ......................................................................................................................15 1.10 Autorisation............................................................................................................16 1.11 Restriction ..............................................................................................................17 1.12 Valeur .....................................................................................................................20 1.13 Fonction système & Autorisation système .............................................................23

2. Organisation de la gestion .................................................................................................25 2.1 Gestion des rôles versus Gestion d'application.......................................................25 2.2 Gestion des rôles ....................................................................................................26

2.2.1 Principes ..................................................................................................................... 26 2.2.2 la Structure Standard des Rôles .................................................................................. 27 2.2.3 Rôle avec attribution implicite................................................................................... 28

2.3 Gestion d'application ..............................................................................................29 3. Fonctionalités de Gestion ..................................................................................................30

3.1 Gestion de Rôles.....................................................................................................30 3.2 Gestion d'application ..............................................................................................32 3.3 Quand est-ce que les modifications au niveau des autorisations sont visibles pour un utilisateur ?...................................................................................................................34

Authorisations - Manager Manual v3.2 F.doc / Concepts ii


1. Concepts Ce chapitre explique de manière plus détaillée les concepts les plus importants de la gestion des autorisations : de quelles données sont-ils constitués ?, quel est leur rôle dans le contrôle des autorisations et/ou à l'écran de l'utilisateur ?

La figure ci-dessus donne un aperçu immédiat de ces concepts et illustre schématiquement les liens mutuels. La légende des couleurs indique qui gère quelles données.

1.1 Application Le terme "application" est aussi vieux que l'informatique proprement dite; mieux encore : aussi vieux que l'ordinateur. Il provient probablement d'une abréviation de logiciel d'application, lequel – contrairement au logiciel système, le logiciel qui doit permettre la commande de l'ordinateur – a réalisé son premier traitement sensé avant l'ordinateur. Ce sont donc les applications qui se chargent de ce traitement. Le terme "application" n'est guère significatif en soi, mais toutes les tentatives de le remplacer par de meilleures alternatives telles que "système informatique" ont malheureusement échoué.

Authorisations - Manager Manual v3.2 F.doc / Concepts 1


La meilleure définition d'une application est dès lors indirecte : un ensemble plus ou moins cohérent et achevé d'objets.

Application : identification codée sous la forme AnnnC, où "nnn" – le numéro de l'application – est attribué par le Bureau des Projets; le "C" du suffixe est l'abréviation de "Composants" et indique qu'il s'agit d'une application dans le cadre du Portail.

Nom: un titre ou une description courte en quatre langues de la quelle l’application est connue par les utilisateurs; néerlandais (N), français (F), anglais (E pour English) et allemand (D for Deutsch).

Plate-forme : plate-forme technique sur laquelle sont construites la logique applicative (business logic) et la banque de données de l'application.

Server: URL du serveur d’application sur lequel l’application est installée. Link: URL de la home page de l’application; celle-ci est affichée au clique de

l’application dans le menu. Définition : zone de texte libre pour la documentation de l'application.

VISUELLEMENT Une application n'apparaît dans le menu d'un utilisateur que s'il a été assigné à un ou plusieurs rôles ayant accès à l'application.

Il est impossible d'enrayer la tendance selon laquelle les différentes applications présentent toujours plus d'interconnexions (des données d'une application A ont une relation avec des données d'une application B). Les différentes applications vont contenir toujours plus de types d'informations, de sorte qu'il subsistera toujours moins d'informations automatisées entre les différentes applications. Les applications ne sont plus des îlots d'informations, elles vont toujours plus s'intégrer les unes aux autres. A mesure que cette tendance se poursuit, la répartition des informations en applications isolées devient progressivement vide de sens, superflue, voire même ennuyeuse.



En tant que groupe d'objets, une application sert principalement à conserver une vue d'ensemble claire de la grande quantité d'objets, et à la maintenir gérable.

1.2 Objet Ces données reprises dans une application sont de types ou genres différents : factures, clients, produits, fournisseurs, ... dans une application financière. Il s'agit des objets, les grands concepts avec lesquels on travaille dans l'application.

Entre deux objets, il peut y avoir une relation; une facture, par exemple, est toujours destinée à un client déterminé. Toute occurrence de l'objet Facture est liée à une occurrence de l'objet Client. Les relations et les objets d'une application constituent ensemble un réseau, un ensemble logiquement cohérent.

Des relations sont également possibles entre des objets de différentes applications, elles constitueront à leur tour un réseau.

Objet : la description en quatre langues de l'objet; constitue également l'identification, mais doit seulement être unique au sein de l'application; modifiable par la fonction batch "Objet – modifier nom"; l'application à laquelle appartient l'objet n'est pas affichée explicitement comme un champ; en effet, l'objet concerne toujours l'application proprement dite à partir de laquelle l'écran "Objet - consulter" est lancé (l'application est renseignée en haut à droite).

Batch : Oui ou Non; Oui signifie que l'objet mentionné est un objet batch; Non signifie qu'il ne s'agit pas d'un objet batch; un objet batch ne peut avoir que des fonctions batch; un objet non-batch peut avoir des fonctions aussi bien normales que batch.

Dépliable : dépliable signifie qu'en cliquant sur l'objet dans le menu, les fonctions du menu apparaissent; un nouveau clic permet de refermer l'objet. Un objet non dépliable doit avoir une fonction de préférence (cf. ci-après).

Fonction de préférence : il est possible de désigner l'une des fonctions de l'objet comme fonction de préférence; en cliquant sur l'objet dans le menu, il est aussitôt exécuté cette fonction de préférence. Dans de nombreux cas, la fonction Liste est recommandée à cet effet, mais ce n'est pas obligatoire.

Numéro de séquence : il permet d'indiquer l'ordre de représentation des objets dans le menu, soit directement sous application (objet hors groupe d'objets), soit dans son groupe d'objets (cf. ci-après).

Groupe d'objets : groupe d'objets auquel l'objet appartient. Définition : zone de texte libre pour la documentation de l'objet.

Les objets ne jouent aucun rôle direct dans le contrôle d'autorisation, mais bien dans l'utilisation de l'application : ils constituent le menu de l'application.



VISUELLEMENT Un objet apparaît dans le menu d'un utilisateur s'il dispose d'une autorisation pour une ou plusieurs fonctions, affichées dans le menu, de l'objet.

Ce sont les concepts que les utilisateurs finaux connaissent; ils font dès lors office, pour l'utilisateur, d'indicateurs lui permettant de retrouver son chemin dans l'application.

1.3 Groupe d'objets Pour éviter que le menu d'une application ne devienne une longue liste non traitable d'objets, il est prévu la possibilité de rassembler les objets prévus dans des groupes d'objets. Dans le menu d'une application, il apparaît d'abord les objets qui ne sont pas repris dans un groupe d'objets, les groupes d'objets venant ensuite. L'ordre des groupes d'objets et celui des objets à l'intérieur d'un groupe d'objets peuvent être déterminés entièrement en fonction des desiderata des utilisateurs.

Nom : en quatre langues, le nom du groupe d'objets tel qu'il apparaîtra également dans le menu (allemand et anglais pas obligatoires).

Numéro de séquence : permet d'indiquer l'ordre de représentation des groupes d'objets dans le menu.

VISUELLEMENT Un groupe d'objets apparaît dans le menu d'un utilisateur si celui-ci dispose d'une autorisation pour une ou plusieurs fonctions, affichées dans le menu, d'un ou plusieurs objets du groupe.

1.4 Fonction

Une fonction se rapporte toujours à un seul objet déterminé. Etant donné que l'objet exprime le type de données, il figure ainsi les fonctions correspondantes pour les opérations qui peuvent être réalisées sur ces données.



AUTORISATION Une ou plusieurs fonctions se rattachent toujours à toute action que l'utilisateur exécute; l'utilisateur peut uniquement exécuter cette action s'il dispose d'une autorisation pour ces fonctions.



Objet : l'objet auquel la fonction appartient; fait partie de l'identification d'une fonction; ne peut être modifié; l'application à laquelle l'objet et donc la fonction appartiennent n'est pas affichée explicitement comme un champ; en effet, l'objet concerne toujours l'application proprement dite à partir de laquelle l'écran "Fonction - consulter" est lancé (l'application est renseignée en haut à droite).

Statut : Actif ou Inactif; normalement, une fonction est active tandis qu'une situation exceptionnelle temporaire est inactive; les autorisations d'une fonction inactive sont automatiquement inactives de sorte que la fonction ne peut être exécutée par personne; le but est d'éviter qu'une telle situation exceptionnelle doive être réalisée par la suppression de toutes les autorisations de la fonction, et par leur rajout ultérieur.

Type : A pour une fonction d'application et S, D ou I pour une fonction système; une fonction normale est de type "Fonction d'application".

Fonction : la description en quatre langues de la fonction, fait également partie de l'identification, mais doit seulement être unique au sein de l'objet; modifiable par fonction batch « Fonction – modifier nom ».

No. Séq : il permet d'indiquer l'ordre de représentation des fonctions d’un objet dans le menu

Tableau : une fonction renvoie toujours à un tableau représentant la source primaire des données pour cette fonction; la fonction "Facture – liste" renvoie donc au tableau Facture; la fonction Facture Modifier également, bien que le tableau Ligne de facture y soit également impliqué, mais pas comme données primaires. Ce renvoi à un tableau est nécessaire en ce qui concerne l'autorisation au niveau occurrence : une restriction peut être d'application sur les autorisations pour une fonction, mais celle-ci doit être prévue comme une restriction possible du tableau d'où la fonction tire ses données primaires.

Batch : Oui ou Non; oui signifie que la fonction mentionnée est une fonction batch; non signifie qu'il s'agit d'une fonction en ligne.

Classe : ci-dessous, les valeurs possibles et leur signification : 01 : Liste 02 : Consulter 03 : Supprimer 04 : Modifier 05 : Ajouter 06 : Demande de relation 07 : Liste de sélection 09 : Gestion d'une relation (fonction appelée) 99 : Fonction spéciale

Lien : cette donnée technique indique l'URL du programme qui sera exécuté si

l'utilisateur lance la fonction; il est géré par les développeurs de l'IUG (interface utilisateur graphique).

Affichage dans le menu : Oui ou Non; en cas de réponse Non, la fonction n'est pas affichée dans le menu. A ne pas confondre avec la "non-dépliabilité" d'un objet qui provoque aussitôt le non-affichage dans le menu de toutes les fonctions de l'objet.

Définition : zone de texte libre pour la documentation de la fonction.



VISUELLEMENT Une fonction n'apparaît dans le menu que si l'utilisateur dispose de l'autorisation à cet effet et si elle a été définie avec "Affichage dans le menu".

1.5 Utilisateur

L'essence d'un contrôle d'autorisation est que les droits dont dispose un utilisateur dans une application, sont définis individuellement. A cet effet, il doit être satisfait à deux exigences.

Toute personne, qui dispose de droits dans une ou plusieurs applications, doit être enregistrée dans la gestion des autorisations.

Toute personne désireuse d'accéder à une application doit, au moment où elle se logue, s'identifier par son identification utilisateur unique (appelée également logon-id) et un mot de passe; le système vérifie ces données (authentification) et autorise l'utilisateur si l'identification utilisateur est connue et le mot de passe lui correspond.

Le concept "Personne" sert précisément à enregistrer des utilisateurs.

AUTORISATION Quand une personne se logue en vue d'utiliser l'une des applications, il est vérifié si la personne est enregistrée comme utilisateur dans le système.

En principe, seule identification utilisateur est ce qu'il est nécessaire de connaître à propos de l'utilisateur. Mais pour le côté pratique de la gestion, il est également enregistré des données supplémentaires (nom, prénom, etc.) afin de pouvoir distinguer avec précision les utilisateurs entre eux. Le déroulement dans la pratique dépend de la catégorie de l'utilisateur.

Collaborateurs internes : il s'agit de membres du personnel de la SNCB dont les données requises peuvent être reprises du fichier du personnel.

Collaborateurs externes : ces données du personnel engagé ne sont pas automatiquement disponibles et doivent être introduites manuellement à l'enregistrement.

Tiers contractuels : il s'agit de clients ou de fournisseurs de la SNCB; ils sont donc en contact avec un service ou une division de la SNCB avec laquelle ils disposent – de façon plus ou moins formelle – d'un accord ou d'un contrat; B-Cargo a en effet établi de véritables contrats avec chacun de ses clients; la carte train d'un voyageur lui fait office de contrat; pour ces utilisateurs, les données nécessaires peuvent donc être extraites de ces contrats, mais doivent donc être introduites manuellement à l'enregistrement.

Tiers anonymes : (coming soon) il s'agit d'utilisateurs ayant accès à nos applications via l'internet; ils peuvent se faire enregistrer par le système d'autorisation même; les données telles que le nom et l'adresse qu'ils y introduisent n'étant naturellement pas vérifiables, de tels utilisateurs seront considérés comme anonymes.



Logon-id: il s'agit du code d'identification de l'utilisateur; pour les

collaborateurs SNCB internes, ce code se compose de 3 lettres et de 4 chiffres provenant de leur numéro d'identification; pour les collaborateurs externes, il présente la forme EXTNNN où NNN est un numéro de suivi; pour les tiers, il présente la forme PNNNNNN où NNNNNN est un numéro de suivi.

Nom : nom de l'utilisateur. Prénom : prénom de l'utilisateur. Numéro d’identification : pour les collaborateurs SNCB internes, il s'agit de

leur identification connue dans le fichier du personnel; pour les collaborateurs externes, ce numéro se présente sous la forme 999900NNN où NNN est le même numéro de suivi que leur logon-id. Les tiers n’ont pas de numéro d’identification.

Catégorie : voir ci-dessus; actuellement, il n'est prévu que les catégories de collaborateurs SNCB internes et externes et les tiers; les données à enregistrer diffèrent fortement, étant donné que celles concernant les collaborateurs SNCB internes sont copiées automatiquement du fichier du personnel; dès qu'il est procédé à son enregistrement, il devient impossible de modifier la catégorie d'un utilisateur.

Langue : langue parlée par l'utilisateur et dans laquelle il sera préférable de s'adresser à lui; pour les collaborateurs SNCB internes, il s'agit de leur rôle linguistique officiel.

Sexe : femme ou homme. Service & Fonction : données administratives tirées du fichier du personnel,

uniquement pour la catégorie des collaborateurs SNCB internes.

VISUELLEMENT Le menu que voit apparaître un utilisateur est complètement personnalisé; il est constitué à partir des autorisations des rôles auxquels l'utilisateur est assigné.

L'écran affiché ci-dessus est d'application pour les utilisateurs des catégories interne et externe. Pour les tiers anonymes rien n'est prévu encore. L'écran ci-dessous est pour la catégorie tiers contractuels.



User-id : apart du logon-id normal, cette catégorie a aussi un user-id. Celui-ci peut être défini à son goût par l'utilisateur même et est utilisé par l’utilisateur pour se loguer; techniquement il se logue avec le logon-id. Le user-id des collaborateurs internes et externes est égal au logon-id.

Société : il est possible de spécifier le nom de la société à partir du 1er août 2006.

Rue, numéro, boîte postale Code postale, commune Pays Téléphone GSM E-mail : l’adresse electronique est utilisé, entre autre, pour la modification du

mot de passe.. Quand un utilisateur modifie son mot de passe, la modification se fait à l’arrière-plan et l’utisateur doit attendre le message electronique avec la confirmation de la modification. Le message est envoyé à cet adresse electronique pour les tiers.



1.6 Rôle

Le but principal du concept "rôle" est d'éviter que des droits d'utilisateur ne doivent être attribués à des utilisateurs individuels, ce qui constituerait une gestion à facteur de travail très élevé. Les utilisateurs sont regroupés dans des rôles et les droits sont alors octroyés à ces rôles.

AUTORISATION Les accès aux applications et les autorisations pour des fonctions sont accordés aux rôles, et non aux utilisateurs individuels.

Ce regroupement d'utilisateurs semble nuire à l'individualité des autorisations octroyées, mais il est toujours possible naturellement de prévoir un rôle qui ne sera assumé que par une poignée d'utilisateurs, voire même un utilisateur unique.

Un rôle constitue donc une répartition des utilisateurs en fonction de leurs tâches et de leurs responsabilités, ce qui signifie en fonction du rôle qu'ils assument au sein de l'organisation : instructeur, accompagnateur de train, conducteur de train, préposé au guichet, comptable, etc. Dans ce rôle, il exerce certaines tâches identiques pour tous les utilisateurs qui assument ce rôle. Ces tâches ne se limitent pas à une application; un rôle doit donc être indépendant d'une application déterminée; grâce à son rôle, l'utilisateur doit pouvoir travailler dans toutes les applications qui entrent dans ses tâches.

VISUELLEMENT L'utilisateur ne doit pas faire de choix entre les rôles qu'il assume; il cumule toujours tous les accès et autorisations de ses rôles.

Les rôles dépassent donc les limites des applications. Conséquence : la gestion des rôles doit aussi être indépendante des applications, et ne peut donc pas être réalisée par les gestionnaires d'application. Les rôles sont plus ou moins liés à une unité de l'organisation et seront également gérés par un nombre limité de personnes par unité. Chaque unité disposera donc d'un rôle pour les gestionnaires des rôles de cette unité.

Il existe 2 types de rôles selon la façon d’attribution:



rôle avec attribution explicite : l’utilisateur doit être attribué explicitement à ce rôle; c’est-à-dire le gestionnaire des rôles doit d’abord créer et puis gérer les attributions au rôle. Plus à ce sujet dans le paragraphe Attribution

rôle avec attribution implicite : l’utilisateur est attribué au rôle au moment où il se logue, si il satisfait aux critères d’attribution. Les critères auxquels l’utilisateur doit satisfaire sont déterminés par le Type rôle auquel le rôle est lié et la valeur des critères définis au niveau du rôle. Le gestionnaire des rôles est seulement responsable pour la gestion du rôle : il ne doit rien faire au niveau des attributions. Ce type de rôle est utile pour des rôles dont la gestion des attributions demande trop de travail; soit quand il y a beaucoup d’attributions, soit quand les attributions changent souvent. Plus à ce sujet dans le paragraphe Type de rôle

Le rôle est aussi applicable aux utilisateurs de la catégorie "tiers" : voyageurs, fournisseurs, partenaires, ...

Les tiers contractuels sont assignés à un rôle approprié par le service ou la division avec laquelle ils sont en contact.

Les tiers anonymes ne sont pas nécessairement assignés à un rôle avec attribution explicite et ont dès lors uniquement accès aux fonctions autorisées pour le rôle « Utilisateur Portail ». Il peut éventuellement leur être donné la possibilité de s'attribuer eux-mêmes des rôles déterminés, mais ce point fait partie de la problématique de la personnalisation du Portail et ne fait l'objet pour le moment d'aucune précision supplémentaire.

Rôle : nom du rôle en quatre langues; doit être unique pour l'ensemble des unités de l'organisation; modifiable par fonction batch "Rôle – modifier nom".

Parent : nom du rôle qui gère ce rôle; ce rôle parent est le seul autorisé à modifier les données du rôle; en outre, le rôle parent est aussi autorisé à gérer les attributions aux rôles enfants; il est obligatoire de compléter le rôle parent, lequel n'est plus modifiable ultérieurement, ce qui signifie que la paternité n'est pas transmissible; lors de la création d'un rôle, il est complété par défaut par le premier des rôles auxquels l'utilisateur qui exécute la création est attribué; la liste de sélection correspondante montre ces rôles; pourtant l'utilisateur ne peut pas seulement choisir parmis ces rôles, mais aussi parmis tous leurs rôles gérés; plus à ce sujet dans le paragraphe Gestion des rôles.



Attribution : nom du rôle qui gère l'attribution d'utilisateurs à ce rôle; elle constitue donc, à côté du rôle parent, un second rôle autorisé à gérer les attributions de ce rôle; lors de la création d'un rôle, il est complété ici par défaut le même rôle que le rôle parent; le champ doit être obligatoirement complété pour les rôles avec attribution explicite, mais le rôle parent peut le modifier à tout instant.

Type d’attribution : attribution Explicite ou Implicite de l’utilisateur au rôle Héritage : Oui ou Non ; la valeur qui est affichée comme héritage quand le rôle

est donné accès à une application ; est une valeur par défaut. Type de rôle : le type de rôle auquel le rôle avec attribution implicite est lié Valeur : la valeur du critère à laquelle l’utilisateur doit satisfaire pour être

attribué au rôle Accès aux fonctions système : Oui ou Non; concerne les fonctions système

pour la gestion des données indépendantes de l'application; "Oui" signifie que ce rôle peut avoir des autorisations système pour des fonctions de système indépendantes de l’application pour ces données.

Définition : zone de texte libre pour la documentation du rôle.

1.7 Attribution

L'attribution est l'enregistrement de l'appartenance d'un utilisateur à un rôle déterminé avec attribution explicite. Un utilisateur peut toutefois être assigné à un ou plusieurs rôles et à l'inverse, un rôle peut être attribué à un ou plusieurs utilisateurs. Les rôles sont conçus de telle façon qu'un utilisateur appartient souvent à un seul rôle, et de telle façon que la majorité des utilisateurs appartiennent au plus à une poignée de rôles.

AUTORISATION Par l'attribution d'un rôle, un utilisateur se voit octroyé la libre disposition de toutes les autorisations et accès de ce rôle.

Un utilisateur dispose de toutes les autorisations et accès de la totalité des rôles auxquels il est assigné.



Il est également possible qu'un utilisateur assume un rôle pendant une durée limitée. C'est par exemple le cas lorsqu'une personne doit remplacer un collègue; l'attribution devrait être supprimée après le retour du collègue. Pour faciliter la gestion des attributions, il est prévu la possibilité de donner à une attribution une durée de validité limitée, à l'aide d'une date de début et d'une date de fin. Les attributions expirées seront supprimées périodiquement.

Rôle : nom du rôle auquel l'utilisateur est assigné. Logon ID: identification de l'utilisateur qui est assigné au rôle. Il s’agit bien du

logon-id et pas du user-id qui peut être déterminé par les tiers. Nom : nom de l'utilisateur attribué. Date de début : date de commencement de la validité de l'attribution; la date

actuelle est proposée par défaut à la création d'une attribution. Date de fin : date de fin éventuelle de la validité de l'attribution.

Pour toute personne faisant partie de l'organisation, il se pose la question de savoir à quel(s) rôle(s) elle doit être assignée. L'attribution d'utilisateurs à un rôle doit être gérée par l'unité à laquelle la personne appartient. Cette compétence peut être donnée à un rôle spécifique, par ex. le rôle des gestionnaires de personnel de cette unité.

Exemple Un rôle "Gestion CA TR" peut attribuer des utilisateurs à tous les rôles du

CA TR. Un rôle "Gestion conducteurs" ne peut assigner que des conducteurs au rôle

"Conducteur".

1.8 Type de rôle

Type de rôle détermine les critères auxquels l’utilisateur doit satisfaire pour qu’il soit attribué implicitement à un rôle de ce type.

Type de rôle est géré par les gestionnaires de système; les rôles liés au type de rôle sont gérés par les gestionnaires des rôles. Il existe 3 types de rôle:



Utilisateur application actuelle : un rôle de ce type est créé par application et reçoit automatiquement le nom « Utilisateur appl AnnnC » dont nnn est le numéro de l’application. La valeur du rôle est l’application, c’est-à-dire « AnnnC ». Tels rôles sont les seuls qui sont liés à une application ; le rôle ne peut avoir accès qu’à l’application mentionnée dans la valeur. Ces rôles héritent toutes les attributions des autres rôles qui ont accès à l’application. Au niveau de l’accès il faut indiquer si les attributions du rôle sont héritées par le rôle « Utilisateur appl AnnnC » Les rôles de ce type sont utiles dans des applications qui ont des fonctions qui doivent être disponibles à beaucoup de rôles : au lieu de créer les autorisations pour chaque rôle il suffit de la créer pour le rôle « Utilisateur appl AnnnC »

Car les rôles sont liés à l’application ils ne peuvent être autorisés que pour des fonctions d’application ou des fonctions système dépendantes d’une application.

Unor : permet de créer des rôles par unité organisationelle. Un rôle de ce type reçoit automatiquement le nom « Unor unor » dont unor est l’unité organisationelle pour laquel le rôle a été défini. La valeur du rôle est egale à l »unor ». Le personnel interne qui appartient à l’unité est attribué implicitement à ce rôle au moment où il se logue. Quand un employé change d’unité ou quand un nouvel employé est embauché, il est automatiquement attribué au bon rôle quand il se logue dans le Portal.

Type d’utilisateur : divise les utilisateurs selon leur catégorie et contient 4 rôles :

o Collaborateur interne : contient tous les employés internes à la SNCB (catégorie I)

o Collaborateur externe : contient le personnel engagé comme des consultants (catégorie E)

o Utilisateur externes : contient tous les tiers comme des partenaires, fournisseur, … (catégorie T)

o Utilisateur Portail : contient tous les utilisateurs définis dans le Portail (catégorie I, E et D)

Type de rôle : nom du type de rôle (allemand et anglais pas obligatoires) Préfix de role : le nom des rôles de ce type est composé du prefix suivi par la

valeur



Composant : vérifie si l’utilisateur est attribué au rôle de ce type Rôle parent par défaut : le rôle qui est affiché comme rôle parent à la création

d’ un rôle de ce type Définition : zone de texte libre pour la documentation du rôle.

1.9 Accès

Un accès est l'autorisation d'un rôle à une application. Ce n'est donc rien de plus que le rattachement d'un rôle à une application, en sous-entendant que ce rôle a accès à l'application.

AUTORISATION Un rôle doit avoir accès à une application pour pouvoir obtenir l'autorisation pour les fonctions de l'application.

Un rôle peut avoir accès à une ou plusieurs applications, et une application peut donner accès à un ou plusieurs rôles.

VISUELLEMENT Dans le menu d'un utilisateur, il apparaît uniquement les applications auxquelles ont accès les rôles auxquels il est assigné.

Rôle : le rôle auquel est accordé l'accès à l'application; l'application n'est pas affichée explicitement comme un champ; en effet, l'objet concerne toujours l'application proprement dite à partir de laquelle l'écran "Accès - consulter" est lancé (l'application est renseignée en haut à droite).

Accès aux fonctions système : oui ou non; indique si le rôle peut recevoir une autorisation pour des fonctions système dépendantes de l’application.

Héritage : Oui ou Non ; indique si les attributions du rôle sont héritées par le rôle « Utilisateur appl AnnnC » si ce rôle a accès à l’application

Exemple

les rôles suivants ont accès à l’application A273C : • « ICT – MAT Développement » avec héritage = ‘N’ • « MAT – WMS Gestion Données de Base » avec héritage = ‘O’ • « MAT – WMS Gestion Factures « avec héritage = ‘O’



• « Utilisateur appl A273C » avec héritage = ‘N’ Si la fonction « Travail – Refresh » est autorisée pour le rôle « Utilisateur appl A273C » cela signifiera que tous les utilisateurs qui sont attribués aux rôles « MAT – WMS Gestion Données de Base » et « MAT – WMS Gestion Factures « pourront exécuter la fonction.

1.10 Autorisation

Une autorisation est une permission accordée à un rôle afin d'exécuter une fonction. Ce n'est donc rien de plus que le rattachement d'une fonction à un rôle, en sous-entendant que cette fonction peut être exécutée par les utilisateurs de ce rôle.

Une fonction peut être autorisée à un ou plusieurs rôles et inversement, un rôle peut avoir une autorisation pour une ou plusieurs fonctions.

AUTORISATION Une autorisation donne la permission, à tous les utilisateurs d'un rôle déterminé, d'exécuter une fonction déterminée.

Fonction : la fonction qui est autorisée. Rôle : le rôle pour lequel la fonction est autorisée. Batch : indique si la fonction mentionnée est une fonction batch. Statut : indique si la fonction mentionnée est active; si la fonction est inactive,

toutes les autorisations de cette fonction sont hors service. Restriction : la restriction éventuelle au niveau "occurrence" touchant la

fonction mentionnée pour le rôle mentionné de l'application.

VISUELLEMENT Les fonctions, pour lesquelles sont autorisés un ou plusieurs rôles auxquels l'utilisateur est assigné, figurent dans le menu.



1.11 Restriction

Tous les concepts décrits ci-dessus constituent un système pour la gestion des autorisations au niveau des fonctions. Le concept "restriction" est nécessaire pour un contrôle d'autorisation supplémentaire, notamment au niveau des occurrences : l'utilisateur peut effectivement exécuter une fonction, mais seulement pour les occurrences satisfaisant à un critère déterminé.

Cela se réalise en spécifiant une restriction dans une autorisation pour une fonction déterminée pour un rôle déterminé. S'il n'est spécifié aucune restriction, les utilisateurs de ce rôle peuvent exécuter la fonction pour l'ensemble des occurrences.

En effet, il n'est pas si facile de spécifier une restriction quelconque dans une autorisation. Les restrictions sont prévues lors de la création de l'application, et obligatoirement sur les tableaux. Dans une autorisation pour une fonction déterminée, il n'est possible d'effectuer un choix que parmi les restrictions prévues sur le tableau de cette fonction.

Les occurrences auxquelles l'utilisateur peut appliquer la fonction doivent donc satisfaire à un critère déterminé.

Dans le cas le plus simple (et très récurrent), il est possible de se représenter ce critère sous la forme d'une comparaison en deux parties : la partie de gauche est un attribut du tableau et la partie de droite une valeur postulée pour cet attribut. Une occurrence satisfait au critère si l'attribut pour cette occurrence est égal à la valeur postulée.

Généralement, le critère est constitué de plusieurs comparaisons auxquelles il doit être satisfait simultanément, chacune étant composée, d'une part, d'un attribut placé à gauche et, d'autre part, d'une valeur, de plusieurs valeurs ou d'une portée de valeurs à droite. Un opérateur (=, <, >, ...) réalise la séparation des deux parties.

La partie de gauche provient de la restriction; les valeurs postulées et l'opérateur proviennent des données valeur de l'utilisateur. Ces données sont donc déterminées par utilisateur individuel et sont gérées de la même façon que les attributions aux rôles.

AUTORISATION En cas d'autorisation avec restriction, l'utilisateur ne peut exécuter la fonction autorisée que pour des occurrences pour lesquelles les attributs spécifiés dans la restriction correspondent aux valeurs spécifiées pour l'utilisateur.



Une restriction consiste donc essentiellement en un ensemble d'attributs. En effet, ces attributs doivent faire partie du tableau auquel l'autorisation (via la fonction) se rapporte.

Restriction : un code identifiant de 5 chiffres. Type : il y a deux possibilités :

"S" : restriction système : il s'agit des restrictions déjà prévues dans le système des autorisations et pour lesquelles, au cours du développement d'une application, il ne doit plus être prévu que les attributs correspondants dans les tableaux souhaités; exemple-type : numéro d'identification du personnel;

"A" : restriction application : une restriction normale définie dans le cadre du développement de l'application qui gère aussi bien les valeurs que les fonctions correspondantes; c'est le seul type de restrictions que les développeurs peuvent créer et gérer.

Nom : une courte dénomination en quatre langues qui reflète l'essence du critère.

Définition : zone de texte libre pour la documentation de la restriction. Détermination de valeur : la façon dont les valeurs postulées sont déterminées

pour les utilisateurs; il existe deux possibilités : "I" : à introduire : la valeur doit être introduite explicitement par le

gestionnaire et est sauvegardée dans la banque de données des données d'autorisation;

"A" : automatiquement : la valeur n'est pas sauvegardée, mais est calculée automatiquement par le sous-programme dès qu'elle s'avère nécessaire (voir ci-après).

Sous-programme : le sous-programme qui calcule la valeur de manière ad hoc (cf. détermination de valeur "A") ou qui valide la valeur introduite.

Liste de sélection : lien vers la fonction qui représente les valeurs éventuelles que la valeur peut adopter (uniquement dans le cas de la détermination de valeur "I").

Origine : plate-forme d'où provient la valeur; uniquement nécessaire pour le côté technique de la validation de valeurs à introduire ou pour le calcul de valeurs déterminées automatiquement : "A" : Adabas; "O" : Oracle.



Nombre d'attributs : nombre d'attributs faisant partie de la restriction; maximum 10; surtout important pour les attributs hiérarchiques.

Nom : nom de l'attribut. Format : format de l'attribut : Alphanumérique, Numérique, Date, Heure. Alphanumérique : nombre de positions d'un attribut alphanumérique. Avant la virgule : nombre de positions avant le signe décimal d'un attribut

numérique. Après la virgule : nombre de positions après le signe décimal d'un attribut

numérique.

La restriction est imposée à l'utilisateur par l'autorisation qu'il possède pour une fonction déterminée. Via les différents rôles auxquels il est assigné, l'utilisateur peut disposer de plusieurs autorisations pour la même fonction, dans lesquelles la restriction spécifiée peut effectivement varier. Dans ce cas, l'utilisateur a le choix parmi ces différentes restrictions.

VISUELLEMENT Dans la partie inférieure de l'écran, l'utilisateur peut effectuer un choix parmi les restrictions qui lui sont imposées pour cette fonction et sélectionner celle qu'il désire utiliser.

Outre l'onglet avec les attributs, il y a encore l'onglet qui donne une vue d'ensemble des Tableaux sur lesquels la restriction est prévue.

Application : application à laquelle appartient le tableau. Nom raccourci : abréviation ou code en deux positions du nom du tableau;

constitue – avec l'application – l'identification du tableau. Nom : nom du tableau.

Un tableau qui figure dans cette vue d'ensemble doit naturellement contenir tous les attributs de la restriction. Si un tableau figure dans cette vue d'ensemble, cette restriction peut être imposée lors de l'autorisation d'une fonction qui possède ce tableau en source de données primaire.

L’onglet ‘Valeurs’ permet de vérifier quels utilisateurs ont reçus une certaine valeur manuelle pour une certaine restriction.



1.12 Valeur

AUTORISATION La valeur, attribuée à un utilisateur pour une restriction déterminée, détermine pour quelles données il peut exécuter une fonction pour laquelle il dispose d'une autorisation avec cette restriction.

La valeur n'est pas un objet autonome : les valeurs appartiennent toujours à un utilisateur déterminé et sont dès lors considérées comme une partie de l'objet Utilisateur. Les valeurs sont gérées au départ de l'écran "Utilisateur - consulter".

Sur l'onglet "Valeur", il est affiché l'aperçu des valeurs normales pour l'utilisateur, c'est-à-dire les valeurs pour des restrictions avec détermination de valeur "à introduire".

Restriction : identification et nom de la restriction à laquelle la valeur se rapporte.

Default : indication si la valeur est la valeur par défaut. Chaque restriction peut avoir une valeur par défaut.

Valeur (initiale) : valeur (ou valeur de début de la portée s'il est également complété une valeur finale; ceci n'est pas encore opérationel).

Valeur finale : valeur finale d'une portée (pas obligatoirement complétée; ceci n'est pas encore opérationel).



Opérateur : opérateur qui détermine de quelle façon la valeur est comparée au contenu de l'attribut de la restriction; les opérateurs possibles sont les suivants : =, <>, >, <, >=, <=; si une restriction est appliquée sur un Tableau du type Adabas, alors seul l'opérateur = est possible.

Un utilisateur peut avoir plusieurs valeurs pour une même restriction : si cette restriction lui est imposée pour une certaine autorisation, il a accès à toutes les occurrences correspondant à l'une de ses valeurs. S'il s'agit d'un écran Liste ou d'un écran Consulter, l'utilisateur peut/doit choisir l'une des valeurs qui lui sont attribuées. L'utilisateur verra donc toujours les données auxquelles il a accès, et ce de façon groupée par valeur qui lui a été attribuée.

Quand l’utilisateur demande un écran Liste ou Consulter à partir du menu, il n’a pas encore pu choisir une valeur pour laquelle il veut avoir la liste ou consultation. La première valeur de la restriction est utilisée. Cette valeur n’est pas nécessairement la valeur que l’utilisateur utilise souvent. En définissant une valeur comme valeur par défaut, les ecrans Liste et Consulter commençeront avec cette valeur. L’utilisateur a la possibilité de definir une valeur comme valeur par défaut au niveau de son « Profil ».

Dans le cas d'une restriction, il peut être mentionné une valeur initiale et une valeur finale, ce qui a la signification d'une portée : l'utilisateur a alors accès à toutes les occurrences dont le contenu l'attribut de la restriction est situé dans cette portée (opérateur =) ou inversement, hors de cette portée (opérateur <>).

Pour les valeurs enregistrées, il est possible de retrouver des valeurs concernant une restriction qui n'est impliquée dans aucune autorisation de l'utilisateur. Par exemple du fait que la restriction imposée d'une autorisation a été supprimée ou du fait que l'ensemble de l'autorisation a été supprimé. De telles valeurs sont donc superflues; elles sont dès lors supprimées périodiquement.

L’onglet « Valeurs » contient les mêmes valeurs que l’onglet « Valeur ». La différence entre ces 2 onglets se situe au niveau de la gestion des valeurs : sur l’onglet « Valeur » on gère les valeurs une par une tandis que sur l’onglet « Valeurs » on sait gérer plusieurs valeurs pour un certain utilisateur. Le premier onglet est prévu parce que, à cause d’une restriction technique, il n’est pas possible de gérer plus que 60 valeurs sur le deuxième onglet.



Dans l'onglet "Val-Auto", il n'est affiché à vrai dire aucune valeur, mais les restrictions à détermination de valeur automatique imposées à l'utilisateur via l'une de ses autorisations.

Les valeurs correspondantes seront ensuite affichées en cliquant sur le bouton adjacent.

Dans l'onglet "Manquantes", il est également affiché des restrictions imposées à l'utilisateur via l'une de ses autorisations, mais pour lesquelles il ne lui a été attribué aucune valeur.



L'absence d'une valeur a des conséquences : si l'utilisateur veut exécuter une fonction pour laquelle il est autorisé, mais avec la restriction pour laquelle la valeur fait défaut, il verra apparaître le message d'erreur signalant que la valeur correspondante n'a pas été trouvée. Il ne pourra donc pas exécuter la fonction.

Ce problème peut être résolu en ajoutant une valeur pour la restriction concernée dans l'onglet des valeurs enregistrées.

1.13 Fonction système & Autorisation système Quoi ?

Les fonctions système sont présentes pour toutes les opérations en rapport avec la gestion des autorisations proprement dite; elles permettent la gestion de tous les concepts décrits ci-avant.

Les autorisations système sont identiques aux autorisations ordinaires, mais pour les fonctions système. Tout comme les autorisations ordinaires, il est attribué des autorisations système à un rôle. La signification est la suivante : les utilisateurs assignés à un rôle peuvent exécuter la fonction système en question.

Qui ? Les utilisateurs normaux n'ont aucun accès aux fonctions système, hormis aux fonctions système consultatives. Les fonctions système sont donc destinées à des groupes particuliers d'utilisateurs qui prennent chacun à leur compte une partie de la gestion des informations concernant les autorisations :

Gestionnaires d'application : accès et autorisations de leur application; Développeurs d'application : objets, fonctions et tableaux de leur application; Gestionnaires de rôles : rôles, attributions et valeurs; Gestionnaires de système : applications, restrictions, utilisateurs et les

fonctions système proprement dites.

Pour plus d'informations, veuillez consulter le chapitre Organisation de la gestion.

Quelques exemples Des gestionnaires d'application ont besoin de l'autorisation système pour

"Accès Ajouter" et "Autorisation Ajouter"; suivant la demande, ils doivent pouvoir donner à certains rôles l'accès à leur application et la possibilité d'y exécuter certaines fonctions.

Des développeurs ont besoin de l'autorisation système pour "Objet Ajouter" et "Fonction Ajouter"; à mesure que le développement de l'application progresse, ils doivent pouvoir ajouter des objets et des fonctions.

Dans le Menu Les fonctions système apparaissent distincte dans le menu. Les gestionnaires d'application et gestionnaires de rôles pourront y voir en effet toutes les fonctions système pour lesquelles ils sont autorisés.

Les fonctions système pour la gestion des rôles et celles pour la gestion d'application ne figurent pas de la même manière sur ce menu.

Les fonctions système pour des données "utilisateurs" et "rôles" dépassant l'application apparaissent directement dans le menu en cliquant sur l'application « Autorisations générales ».



Les fonctions système pour la gestion des données "accès" et "autorisations" dépendantes de l'application sont réparties par application, sous le groupe d’objet « Gestion autorisations ». Les différentes fonctions système sont alors mentionnées par application.

Une répartition identique est d'application aux fonctions système pour lesquelles les développeurs d'application et les gestionnaires système sont autorisés.

Les fonctions système pour les données "restrictions", "utilisateurs" et "applications" dépassant l'application figurent directement dans l’application « Autorisations générales ».

Les fonctions système pour la gestion des données "groupes d'objets", "objets", "fonctions", "tableaux" et "composants" dépendantes de l'application sont réparties par application sous le groupe d’objet « Gestion autorisation ».

Applicable Cette présentation différente n'est effectivement pas due au hasard.

Les autorisations système pour les fonctions système dépendantes de l'application sont attribuées au sein d'une application, et ne concernent dès lors que l'exécution de cette fonction système à l'intérieur de cette même application. La personne qui aura besoin de cette même fonction système dans plusieurs applications devra obtenir l'autorisation système correspondante dans chacune de ces applications.

Les autorisations système pour les fonctions système dépassant l'application ne doivent en effet être attribuées qu'une seule fois.



2. Organisation de la gestion 2.1 Gestion des rôles versus Gestion d'application

La norme "Gestion des autorisations" dont il est question ici est le premier système à grande échelle pour la gestion d'accès qui dépasse les limites des applications distinctes. Le concept Rôle est notamment dissocié des applications : un rôle dispose en général d'autorisations dans plusieurs applications. En même temps, il n'a été introduit aucune nouvelle limite : tout rôle peut obtenir des autorisations dans chacune des applications. Exception à la règle : le rôle « Utilisateur appl AnnnC » qui ne peut avoir accès qu’à l’application mentionnée dans la valeur du rôle. Plus à ce sujet dans le paragraphe Type de rôle.

L'essence de la gestion journalière des autorisations peut être scindée en deux parties : Gestion des rôles : création de rôles, attribution d'utilisateurs à ces rôles et

attribution de valeurs aux utilisateurs. Car cette gestion est indépendante des applications, les fonctions de système se trouvent sous une application séparée, c’est-à-dire « Autorisations générales ».

Gestion d'application : attribution aux rôles, d'un accès aux applications et d'une autorisation aux fonctions des applications. Ces données doivent être gérées application par application. En conséquence, les fonctions système concernées se trouvent dans le menu sous l’application même, sous le groupe d’objet « Gestion d’autorisation ».

Organisation par Unité Il va de soi d'attribuer cette gestion à une seule instance par unité dans l'organisation de la SNCB (directions et services staff). Cette instance exécutera les deux parties de la gestion sans toutefois les ressentir comme étant deux parties différentes. Le gros de la gestion y consistera en effet à placer le propre personnel de l'unité dans des rôles qui se gèrent seuls, et à donner des accès et autorisations à ces rôles dans les applications propres.

Dépassement des limites d'application Cela signifie une simplification sensible : un utilisateur ne doit pas être défini séparément dans chacune des applications dans lesquelles il a besoin d'autorisations; une seule attribution à un rôle suffit. Ce rôle reçoit ensuite des autorisations dans les différentes applications.

Dépassement des limites d'unité Un gestionnaire d'application peut également donner, dans ses applications, des autorisations à des rôles dont il n'est pas le gestionnaire, ce qui veut dire à des rôles d'autres unités. Le système dépasse les limites entre les unités.

La situation, dans laquelle des collaborateurs d'une unité A requièrent des données situées dans des applications d'une unité B, existe bel et bien aujourd'hui. Avec l'informatisation croissante, ce besoin ne fera qu'augmenter.

Les systèmes d'autorisation liés à une application sont toutefois perturbés; ils peuvent résoudre de problème de deux façons :

Authorisations - Manager Manual v3.2 F.doc / Organisation de la gestion 25


Dans une application d'une unité A, il est ajouté – en concertation avec l'unité B – une fonction donnant accès aux données indispensables de l'unité B; l'avantage majeur est que l'unité A gère de manière autonome les autorisations à cette fonction; l'inconvénient majeur est qu'une intervention de développement d'ICT est requise.

Les personnes concernées sont ajoutées dans l'application par l'unité B, en tant qu'utilisateurs, à la demande de l'unité A, et y reçoivent une autorisation pour une fonction convenue; l'inconvénient majeur est que pour chaque utilisateur, il est exigé l'intervention de l'unité B sans que cette intervention n'apporte une quelconque plus-value; l'avantage majeur – dans le cas où il s'agirait d'une fonction existante – est qu'il n'est requis aucune intervention de développement de la part d'ICT.

Le présent système offre une combinaison pratique des deux solutions décrites ci-avant :

Une unité B donne, grâce à une intervention unique, l'autorisation pour une fonction convenue à un rôle X de l'unité A.

L'unité A gère ensuite de manière autonome l'attribution d'utilisateurs au rôle X.

Dans un tel cas, la division de la gestion en gestion des rôles et en gestion d'application prend tout son sens : le rôle X est géré par l'unité A, mais reçoit (une partie de) ses autorisations de l'unité B.

2.2 Gestion des rôles

2.2.1 Principes

La signification du concept "Rôle" en tant que catégorie de collaborateurs rend évidente l'attribution de la gestion des rôles aux différentes unités de l'organisation de la SNCB, aussi désigné les business domains. La gestion des rôles peut alors se dérouler parallèlement à la gestion du personnel.

les relations entre les rôles En créant ses rôles subordonnés, le gestionnaire d'un business domain doit tenir compte avec les deux relations que chaque rôle a avec deux autres rôles différents: le rôle parent et le rôle attributeur.

rôle attributeur: peut ajouter, modifier et supprimer des attributions du rôle; rôle parent: peut modifier et supprimer le rôle.

Cette construction a aussi 2 conséquneces: aussi le rôle parent et toute la hiérarchie parent au-dessus du rôle parent

peuvent gérer les attributions; aussi toute la hiérarchie parent du rôle attributeur peut gérer les attributions.



Cette contrôle hiérarchique ne s'applique pas seulement à la gestion des attributions, mais aussi à la gestion des valeurs des utilisateurs attribués.

2.2.2 la Structure Standard des Rôles

le Gestionnaire de Domaine: “<dom> - Gest. Systèmes Information” Pour chaque unité un rôle spéciale de gestion est initialement créé, le gestionnaire de domaine; <dom> représente un code de 1 à 3 charactères qui indique le domaine: R pour Réseau, TR pour Trains, HR pour Human Resources, GDM pour Marchandises, MAT pour Matériel, ICT pour ICT, …

Ce rôle a les propriétés suivantes: son parent est le rôle “ICT – ICT Gestion”, et se trouve donc au sommet de sa

propre hiérarchie parent; il n'est influencé que par le rôle primaire “ICT – ICT Gestion” ce qui n'est pas plus que l'expression de l'inévitable gestionnaire de système qui peut toujours se donner accès;

il dispose initialement de tout les autorisations système nécessaire à la gestion des rôles, accès et autorisations (y-compris l'autorisation système pour la fonction "Autorisation Système - ajouter").

il a accès à tout les applications de son business domain et peut gérer les autorisations et autorisations système dans chaque de ces applications.

strictement dite il n'a pas besoin d'autorisations des fonctoins de ces applica-tions, sauf s'il est compris dans l'utilisation opérationelle de l'application.

L'idée est que ce gestionnaire s'y met à créer les rôles qui correspondent au différents profils des collaborateurs dans son unité. A se sujet il convient de ne pas raisonner en termes d'applications ou autorisations. Plustôt l'inverse: à partir des différents profils de collaborateurs et leurs tâches et responsabilités spécifiques, les rôles sont définis et par après on détermine de quelles applications et de quelles autorisations ces collabo-rateurs ont besoin pour pouvoir exécuter leur tâches et responsabilités. Cette deuxième étappe est d'ailleurs ce qu'on appelle la gestion d'application.

L'avis au gestionnaires de domaine est d'appliquer et de maintenir la structure standard des rôles suivante.

La figure ci-dessous donne un bon exemple. (En anglais le gestionnaire de domaine s'appelle “<dom> - Informations Systems Mngt”)



Rôles Gestionnaire: “<dom> - <description gestionnaire> Dans l'exemple: “TR – Chief Distributor” et “TR – Mngt Repair Men”. Ces rôles sont les utilisateurs à haute autorité dans une ou plusieurs applications. Ils ont le gestionnaire de domaine comme parent et souvent aussi comme attributeur. Ce gestionnaire de domaine leur a délégué des autorisations système plus ou moin larges, eventuellement y compris des autorisations système pour la gestion de rôles. Ils ont aussi des autorisations applicatives en fonction de leur tâches opérationelles, mais l'opérationel n'est pas leur tâche primaire.

Rôles Opérationels: “<dom> - <description opérateur>” Dans l'exemple: “TR – Chief Repair Men” et “TR – Repair Men”. Ces rôles ont essentiellement des tâches et responsabilités opérationelles, et disposent donc à cela des accès et autorisations nécessaires. Normalement ils ne doivent pas gérer des autorisations ou des attributions. Ils ont, si possible, le gestionnaire de domaine comme parent et un des rôles gestionnaire comme attributeur. Dans l'exemple “TR – Chief Repair Men” est une exception typique: le rôle gestionnaire “TR – Mngt Repair Men” est sont parent; le but de cela est que celui-ci peut gérer les attributions de “TR – Repair Men”, enfant de “TR – Chief Repair Men”.

Rôle Développement: “ICT - <dom> Développement” Ce rôle est optionel et a pour but le debugging. Il n'y a que des collaborateurs H-ICT attribués à ce rôle, il n'a pas d'autorisations applicatives, il n'a que des autorisations système pour la gestion des attributions, et il est parent du gestionnaire de domaine. Par cette construction les utilisateurs de ce rôle peuvent s'attribuer eux-même à n'importe quel rôle du domaine (et se supprimer par après) pour reproduir des problèmes signalés.

Une alternative est que, à chaque occasion d'un problème, les collaborateurs de H-ICT sont attribués par le gestionnaire de domaine au rôle approprié, ce qui en pratique peut être ennuyeux.

2.2.3 Rôle avec attribution implicite

Les rôles avec attribution implicite simplifient la gestion des :



attributions : il ne faut pas suivre le mouvement du personnel de trop près. Quand un employé change d’unité organisationelle, le changement sera effective la prochaine fois que l’utilisateur se logue dans le Portail sans intervention du gestionnaire des rôles. Le fait de ne pas devoir attribuer tous les utilisateurs à un rôle soularge en plus les gestionnaires des rôles

autorisations : en autorisant une fonction pour un rôle comme « Utilisateur appl AnnnC » ou « Utilisateur Portail » il ne faut créer qu’une autorisation au lieu de plusieurs.

2.3 Gestion d'application La gestion d'application est également organisée par unité : lors de l'ajout d'une application au système, il en est attribué la gestion à l'unité qui a fait développer le système. En effet, une unité sera en général la gestionnaire de plusieurs applications.

Voilà comment ça se passe : il est donné initialement, au seul gestionnaire de domaine, l'accès à cette application, puis – à l'intérieur de celle-ci – toutes les autorisations système nécessaires.

Le but est que ce rôle de gestionnaire se mette ensuite au travail de lui-même : attribuer l'accès et les autorisations à l'application aux rôles qui en ont besoin. Les rôles en gestion propre et les rôles d'autres unités entre tous les deux en ligne de compte à cet effet.



3. Fonctionalités de Gestion Comme gestionnaire de rôles et/ou applications, vous disposez des fonctionalités suivantes.

3.1 Gestion de Rôles

Rôle liste : des rôles consulter: avec les tables d'association suivantes:

attributions: accès: autorisations: parent de: attributeur de:

ajouter : un rôle avec attribution explicite ajouter (implicite) : un rôle avec attribution implicite modifier nom: fonction batch qui permet de modifier le nom d'un rôle existant

dans une ou plusieurs des 4 langues prévues. extraction: fonction batch qui fourni par e-mail un fichier excel contenant un

nombre d'aperçues d'un rôle: les utilisateurs attribués et leurs valeurs, ses accès, les rôles aux niveaux supérieurs dans son hiérarchie de parent, les rôles aux niveaux inférieurs dans cette hiérarchie, les rôles parent de son rôle attributeur.

supprimer: n'est permit que si le rôle n'a plus d'accès, n'est plus attributeur ni parent d'autres rôles; ses attributions sont supprimé également.

Authorisations - Manager Manual v3.2 F.doc / Fonctionalités de Gestion 30


gestion attributions : offre la possibilité de gérer plusieurs attributions pour un certain rôle au lieu d’attribution par attribution. Les attributions sont gérées sous forme d’une table d’enregistrements modifiables. La fonction est disponible sur la fonction « Rôle – consulter »

gestion autorisations : offre la possibilité de gérer plusieurs autorisations des fonctions système, indépendantes d’une application, pour un certain rôle au lieu d’autorisation par autorisation. Les autorisations système sont gérées sous forme d’une table d’enregistrements modifiables. La fonction est disponible sur la fonction « Rôle – consulter »

Attribution liste : des attributions consulter : les données d’une attribution ajouter: si vous pouvez faire une attribution à un certain rôle depend des rôles

auxquels vous êtes vous-même attribués, comme décrit ci-dessus dans les principes du gestion des rôles; pour le champ Logon-id vous pouvez appeler une list de sélection qui vous permet de choisir entre 3 catégories d'utilisateurs: employées SNCB, collaborateurs SNCB et tiers contractuels. Les tiers contractuels et les collaborateurs SNCB doivent d'abord être explicitement enregistré comme utilisateur; probablement vous n'avez pas l'autorisation à cela et vous devez donc vous adresser aux personnes de “ICT – ICT Gestion”.

modifier: vous ne pouvez modifier que la date de fin; supprimer : d’une attribution copier de rôle à rôle: toutes les attributions d'un rôle A sont copiées vers un

rôle B (voir les explications à l'écran de la fonction même); Il faut avoir les autorisations pour gérer les attributions de rôle B.

Personne & Valeurs liste : des utilisateurs définis dans le Portal consulter : les données d’un utilisateur. Pour gérer les valeurs, vous devez

d'abord cherhcer la bonne personne par les fonctions “Personne – liste” et/ou “Personne – consulter”; dans l'onglet « Valeur » et « Valeurs » de celle-ci vous disposez alors des boutins nécessaires pour ajouter, modifer et supprimer des valeurs.

enrégistrer : pour enregistrer les tiers contractuels modifier : les données d’un tiers copier des valeurs : toutes les valeurs d’un utilisateur pour une ou toutes ses

restrictions peuvent être copier vers un autre utilisateur gestion attributions : offre la possibilité de gérer plusieurs attributions pour un

certain utilisateur au lieu d’attribution par attribution. Les attributions sont gérées sous forme d’une table d’enregistrements modifiables. La fonction est disponible sur la fonction « Personne – consulter »

Restriction & Valeurs liste : des restrictions définies dans le Portal consulter : les données d’une restriction. L’onglet ‘Valeur’ permet de

rechercher quels utilisateurs sont attribués une certaine valeur manuelle d’une certaine restriction.

valeur automatique : fonction batch qui permet de rechercher les utilisateurs qui ont une certaine valeur pour une certaine restriction avec valeur automatique



Autorisation système Les fonctions de cet objet vous permettent de déléguer à d'autres rôles les fonctions des objets décrit ci-dessus.

copier de rôle à rôle: toutes les autorisations des fonctions de système, indépendantes d’une application, d'un rôle A sont copiées vers un rôle B (voir les explications à l'écran de la fonction même);

3.2 Gestion d'application

La gestion d'application (accès, autorisations) concerne toujours une certaine application; il est évidemment possible que vous disposez dans plusieurs applications des autorisations nécessaires à cette gestion. Chaque application, que vous pouvez gérer, contient le groupe d’objet « Gestion autorisations » : environ un menu comme ci-dessous apparait, selon que vous avez une partie ou la totalité des autorisations.

Accès liste : des rôles qui ont accès à l’application consulter : les données d’un accès ajouter: vous pouvez donner accès à l'application à n'importe quel rôle

existant; modifier: le seul champ modifiable est l'accès aux fonctions système; supprimer: toutes ses autorisations applicatives et système dans l'application

sont supprimées également. gestion autorisations : offre la possibilité de gérer plusieurs autorisations pour

un certain rôle qui a accès à l’application, au lieu d’autorisation par autorisation. Les autorisations sont gérées sous forme d’une table d’enregistrements modifiables. La fonction est disponible sur la fonction « Accès – consulter »

gestion syst. autorisations : offre la possibilité de gérer plusieurs autorisations système pour un certain rôle qui a accès à l’application, au lieu d’autorisation par autorisation. Il s’agit bien des autorisations pour les fonctions système dépendantes d’une application. Les autorisations système sont gérées sous forme d’une table d’enregistrements modifiables. La fonction est disponible sur la fonction « Accès – consulter »



Autorisation liste : des autorisations dans l’application consulter : les données d’une autorisation ajouter: autoriser une fonction à un rôle; la liste de sélection pour le champ

Fonction présente les fonctions de l'application actuelle dans laquelle vous êtes en train d'ajouter l'autorisation; l'utilisation de cette liste de sélection est obligatoir; la liste de sélection pour le champ Rôle présente les rôles qui ont accès à l'application actuelle; la list de sélection pour le champ Restriction présente les restrictions prévues pour la table primaire de la fonction déjà choisie.

modifier: vous ne pouvez que modifer ou effacer la restriction; supprimer : une autorisation copier de rôle à rôle: toutes les autorisations d'un rôle A sont copiées vers un

rôle B (voir les explications à l'écran de la fonction même); copier de fnc à fnc: toutes les autorisations d'une fonction A sont copiées vers

une fonction B (voir les explications à l'écran de la fonction même).

Autorisation système Les fonctions de cet objet vous permettent de déléguer à d'autres rôles les fonctions des objets décrit ci-dessus.

Fonction gestion autorisations : offre la possibilité de gérer plusieurs autorisations pour

une certaine fonction au lieu d’autorisation par autorisation. Les autorisations sont gérées sous forme d’une table d’enregistrements modifiables. La fonction est disponible sur la fonction « Fonction – consulter »

Il y a des fonctions système, dépendantes d’une application, qui ne se trouvent pas sous l’application sous “Gestion autorisations”. Il existe aussi un objet « Application » qui contient des fonctions liées à une application. La fonction « extraction » est un exemple et se trouve sous l’application « Autorisations générales ».



Application extraction: fonction batch qui fourni par e-mail un fichier excel contenant un

nombre d'aperçues sur une application: accès, objets, fonctions, autorisations, …et les résultats d'une controle d'intégrité.

3.3 Quand est-ce que les modifications au niveau des autorisations sont visibles pour un utilisateur ?

Les données d’autorisations sont sauvegardées dans une base de données sur le mainframe. Quand un utilisateur se logue, nous recherchons ses rôles et puis les autorisations de ces rôles sur le mainframe. L’utilisateur reçoit un menu personalisé avec ses applications et fonctions autorisées dans sa langue.

C’est possible qu’un gestionnaire d’autorisation ajoute, modifie ou supprime des autorisations pour un rôle auquel un utilisateur logué est attribué. Pour éviter que l’utilisateur doit se reloguer pour avoir ses modifications, il y a un bouton Renouveler

en haut dans le menu pour rafraichir ses autorisations.

En appuyant sur ce bouton, les données d’autorisations sont relues sur le mainframe pour l’utilisateur. C’est comme si l’utilisateur se relogue.

Depuis janvier 2008 il existe un autre système. Ce système ne recherche plus les autorisations ni les autorisations système directement sur le mainframe mais sur un serveur central quand un utilisateur se logue ou rafraichit son menu. Ce serveur contient une copie des autorisations (système) et est constituée comme suite :

Chaque jour toutes les autorisations (système) sont lues sur le mainframe à minuit et sauvegardées sur le serveur central

Après minuit on va rechercher chaque 5 minutes les modifications au niveau des autorisations (système) sur le mainframe

Il est donc possible que certaines modifications des autorisations (système) ne sont visibles qu’après 5 minutes, le temps maximum jusqu’au prochain rafraîchissement de la copie sur le serveur. Le temps jusqu’au prochain rafraîchissement de la copie est affiché en secondes en bas dans le statusbar pour que l’utilisateur puisse avoir une idée du temps qu’il faut attendre. Important : ce temps n’est actualisé qu’après avoir appuyer sur le bouton « Renouveler ».

L’exemple ci-dessus montre que le prochain rafraîchissement de la copie sur le serveur sera fait dans 129 secondes. Ca veut dire que les modifications ne sont pas encore actives pour l’utilisateur parce que le système se base encore sur les anciennes données. L’utilisateur peut appuyer sur le bouton « Renouveler » pour actualiser ce temps.

Cette façon de travailler ne concerne que les autorisations et les autorisations système. Les modifications au niveau d’utilisateur et attribution ne sont visibles qu’après avoir se loguer. Le bouton « Renouveler » ne rafraîchit pas ces données. Il faut se reloguer.



Les modifications au niveau des valeurs ont directement éffet en ré-exécutant la fonction qui est autorisé avec la restriction des valeurs. Il ne faut pas appuyer sur le bouton « Renouveler » et se reloguer.

Toutes les applications Portal vont migrer vers ce nouveau système à terme. Tant que la migration n’est pas faite pour toutes les applications, il y aura des applications qui utilisent l’ancien système et d’autres qui utilisent le nouveau système. Pour savoir quel système est utilisé par une application, il faut regarder en bas dans le statusbar. Si le mot « Refresh » n’est pas affiché, comme dans l’image ci-dessus, l’application utilise l’ancien système : les données sont lues directement sur le mainframe. Il n’y a donc pas de retard.


Documents

Gestion des Autorisations - users.b-rail.beusers.b-rail.be/portal_doc/prod/A966C/F/Authorisations - Manager... · 3.2 Gestion d'application ... Gestion des Autorisations AUTORISATION