SAS Token Authentication

[xav2229]

Salut,

Voila le topo:

Je compte utiliser la fonctionalité "SAS Token Authentication" afin de démarrer des WorkSpace avec un user générique et pas des users nominatifs.

Le but recherché est de simplifier la gestion des droits UNIX au niveau du user générique.
Un autre but est d'utiliser PAM afin de ne pas créer une myriade de users sur la bécane.

Cela me semble une bonne option puisse que je n'ai "que" EGuide comme client à ma plateforme avec à la limite SAS Stored Process Web Application.

Avez vous des contre-indications à ce choix?

ps : pour l'instant tout fonctionne nickel

tcho

xav

[sasadm]

Salut,

pour couper les cheveux en 4 je dirais la sécurité. Toute personne qui "voit" l'objet de métadonnée "serveur" pourra lancer des sessions.
Mais si c'est ce que tu veux (et cela doit l'être puisque vous n'avez que GUIDE), cela ne pose pas de problème.
Pour info, une alternative au SAS token est de rassembler tous les comptes utilisateur dans un groupe de métadonnées rattaché à ton compte générique (onglet compte). Il faut également que ce groupe fasse partie de SAS General Server et qu'il ait le droit ReadMetadata sur le serveur Workspace. Enfin il faut que ton compte générique possède le même domaine d'authentification que ton serveur.

[datametric]

pour des raisons de sécurité effectivement et puis peut-être pour tes kill -15 si tu veux attraper le user 'fautif' via le ps -ef.

Autrement, je n'ai pas vu d'inconvénient. Voit quand même avec les gars de la sécurité quand même pour confirmer qu'un user générique est accepté.

[xav2229]

Merci de vos réponses.

De toutes façons je dois créer un groupe de Metadadonnées afin de stocker les users qui ont droit à tel/tel Application Server (oui il y en aurait plusieurs).

J'avais pensé à la solution avec "SAS General Server", cependant dans la documentation j'avais lu des limites quand à la portée des "Authentication Domain", comme quoi les WorkSpace n'y faisaient pas attention (faudrait que je retrouve la doc)

C'est vrai que je n'ai pas pensé au problème de l'identification de la session pour le kill.

je pourrais m'en sortir avec le pid :
Je le trouve dans la SMC

Code :

sassrv01  536768 1249502   0   Dec 08      -  0:00 /apps/sas/Engines/sas92/SASFoundation/9.2/sasexe/sas -noterminal -noxcmd -netencryptalgorithm SASProprietary -metaserver jojo -metaport 8563 -metarepository Foundation -locale en_US -objectserver -objectserverparms protocol=bridge spawned spp=45261 cid=21 classfactory=440196D4-90F0-11D0-9F41-00A024BB830C server=OMSOBJ:SERVERCOMPONENT/A5NPWD2V.AU000005 cel=credentials dnsMatch=parva2406516.fr.net.intra

et avec l'IP du fautif :

Code :

1
2
3
4
# lsof -i|grep 536768
lsof: WARNING: compiled for AIX version 5.3.0.0; this is 5.3.
sas        536768 sassrv01    3u  IPv4 0xf1000600019f5b98        0t0  TCP *:51609 (LISTEN)
sas        536768 sassrv01   20u  IPv6 0xf1000600017ad398   0t242928  TCP parva2406516:8594->172.17.49.31:dic-aida (ESTABLISHED)

je compte redémarrer les serveurs SAS une fois par semaine.

xav

[datametric]

Plusieurs Application Server = plusieurs SASApp ?

je viens de faire un serveur qui accueille le dev, recette et l'intégration. J'ai trois SASApp.
Effectivement j'ai trois groupes et trois ACT. Chaque SASApp possède son Workspace. N'oublie pas d'y mettre le groupe Admin pour la gestion.

Tu pourrais retrouver ton doc car je ne vois pas ce que tu veux dire.

Tu dupliques les répertoires ou chacun de tes Workspace appelle le même sh ?

eh mais tu es en aix 5.3 lol

[xav2229]

Envoyé par datametric

Plusieurs Application Server = plusieurs SASApp ?

Oui

Envoyé par datametric

Tu dupliques les répertoires ou chacun de tes Workspace appelle le même sh ?

Oui je le fait via le shell qui permet de scripter la configuration.
Cela me fait pas mal de choses : l'arborescence physique et la déclaration du server dans les metadata.

Envoyé par datametric

Tu pourrais retrouver ton doc car je ne vois pas ce que tu veux dire.

Envoyé par SAS Doc

SAS 9.2 Intelligence Platform - Security Administration Guide.pdf
Is the workspace server assigned to the wrong authentication domain?
If so, credential reuse might be impaired. In most configurations, the workspace server should be in DefaultAuth.

=>Unless you resolved mixed providers by putting the workspace server in its own authentication domain.


If you choose to store passwords for the workspace server, the relationships would be comparable to the depiction of the Oracle DBMS,
OracleAuth authentication domain, and Oracle logins. For example, you might put the workspace server in WorkspaceAuth and create individual and group logins in that authentication domain

J'aime bien les docs de SAS, on y apprend bien le conditionnel
On y voit egalement un peu de tout et son contraire.

Bon je ne pense pas qu'il y ait de problèmes, tu as fait 3 SASApp avec 3 authentication domain?
Puis tu as fait une ACT pour limiter tel/tel user d'accéder au WSP
Puis tu as déclaré les users dans les bons groupes liés a ton ACT
Dans la déclaration des users tu as ajouté des authentication domain qui matchent avec les WSP?

Sans cela ca ne marche pas?

Envoyé par datametric

eh mais tu es en aix 5.3 lol

Ben oui ils le vendent encore !

tcho

[sasadm]

Salut,

Tu peux aussi installer un nouveau serveur applicatif à partir d'un dépot SAS. ça t'évite de te fader la configuration à la main.

J'avais pensé à la solution avec "SAS General Server", cependant dans la documentation j'avais lu des limites quand à la portée des "Authentication Domain", comme quoi les WorkSpace n'y faisaient pas attention (faudrait que je retrouve la doc)

Si je me souviens bien l'Authentication Domain sert à faire le lien entre serveur attaqué et compte (login) d'ouverture de session (à ne pas confondre avec le login du compte utilisateur).

Par exemple si ton compte utilisateur est lié à 2 logins login1 et login2 de domaines respectif domaine1 et domaine2, alors tu ouvriras une session sur SERVERAPP1 avec login1 et sur SERVERAPP2 avec login2. En supposant que SERVERAPP1 ait pour domaine domaine1 et SERVERAPP2... domaine2.