Find AuthDomain of EG-User

[Criptic]

Hey,

I want to know if it is possible to get the AuthDomain of a EG-User.

E.g. I sign into EG7.1 with a profile which has a username and password and an authentication domain. Is it somehow possible to read that domain from a programm (with %put %sysget() for example)?

I'm on SAS9.4M2 and the EG version is 7.1 on Windows. Any help would much appreciated.

Kind regards

David

[Damo]

Hi @Criptic

It might not fully answer your needs but hopefully it will assist you.

EG has some macro-variables you can use.

To display them all, you can simply run:

     %put _all_;

One of the macro-variable is SYSUSERID.

%put &SYSUSERID; returns the user ID (sasdemo in that case):

        26 %put &SYSUSERID;
        sasdemo

With that code (you can take of the options statement if you are already connected to the Metadata Server), you'll have the authentication domains linked to the user. If you have more than one, that's the caveat, you'll have few listed...

options metaserver="your server"
        metaport=8561
        metauser="sasadm@saspw"
        metapass="your password"
        metarepository="Foundation"
        metaprotocol=BRIDGE;

%put &SYSUSERID;
%let person=&SYSUSERID;

data logins;
length userid $32 person uri authuri obj authdomain $256 id $17;
    Userid="";
	person="";
keep userid  person uri id obj authdomain; 
obj="omsobj:Person?@Name='"||"&person"||"'";
arc=metadata_getattr(obj,"ID",id);
arc=metadata_getattr(obj,"Name",person);
rc=1;
    n=1;
association=''; 
put arc= id= obj=;
if (arc=-3) then put "No Persons match (&person).";

else do;
        rc=metadata_getnasn(obj,"Logins",
                            n,
                            uri);

 if (rc > 0) then do i=1 to rc;
   

        /* Walk through all possible associations of this object. */

        arc=metadata_getnasn(obj,"Logins",
                            i,
                            uri);
							put rc=;
				 arc = metadata_getattr(uri, "UserID", Userid);
				 
		       arc2=metadata_getnasn(uri,"Domain",
                            1,
                            authuri);
			*put arc2= authuri=;
         arc2= metadata_getattr(authuri, "Name", authdomain);
         put 'Userid=' UserID $32.;
		 put authdomain=;
        output;
        put uri=;
            end;
	Else put "There are no logins for &person";
	end;
run;

proc print data=logins;
  var person userid authdomain;
run;

Hope that helps.

Cheers,
Damo

[Criptic]

Thank you for your answer.

I looked at %put _ALL_ but the AuthDomain can not be found this way.

Sadly accessing the metadata of user is not an option for me for what I'm trying to do. Maybe I should explain that a little better.

I want to give users a different autoexec depending on some value in their profile. The only two values that I can change are AuthDomain and Description (so if I can access either I'm fine). You might say why not use two different users - my answer to that is that I only have one accepted way to authenticate my users (@saspw user are not okay with our security rules). Next you might say why not use a different level all together - well because only one lib changes and the rest of the libs stay the same. 

If anybody as any other ideas of how to achieve this - I'm open to suggestions

[ronan]

If I understand correctly what you are looking for, viz trying to select an autoexec conditionnaly based upon some user's attribute in metadata, I think it won't work that way. Auhentication domains are no placeholders for tagging users, they're technical artifacts for streamlining authentication processes (for instance : users authenticating with their AD account/pwd, generic DBMS accounts like Oracle authenticating against some LDAP directory etc.). Description field can be reused, but as @Damo has shown, it requires (costly) custom requests in metadata because this information is not presented by default when a SAS session is launched.

If you try to follow the standard SAS 9  guidelines, you might have to create new objects instead,namely

1) a second Workspace Server references in Metadata (Plug-in Server Manager)

2) the corresponding Configuration directory, which comes with some customisable Autoexecs

3) a second metadata Group 

3 4)  some ACTs to redirect users  groups to the first Wk Server or to the 2nd based on their MD group

If you want to spare some extra directories, 2) is not even required sometimes.

With this, the user launches the autoexec conditionnaly without having to devise some custom MD request & custom parameter storage within a user's MD references : this is automatically handled by metadata standard security rules.

[Criptic]

Thank you for your answer, but this doesn't quite get to the core of my problem if I understand you correctly. What I got from your explanation is that you "assign" a user a autoexec based on his medata groups - we are already doing this - in fact every single user has their own specific autoexec which gets generated on metadata changes.

I'm trying to further elaborate on my problem:

 I want to have a user lets call him Mr Pink. Mr. Pink has 5 Metadata Groups, as login authentication he uses his Windows Profile (Windows AD). Now we want to give him the ability to access another lib which contains sensitive information. He is not supposed to see this Lib in his everyday work but he should have the ability to access this Lib when needed.

So the idea is to give him two autoexec one where he has access to things his 5 MD-Groups allow him and another one where he his allowed to use additonally use this special Lib. Limitation is that the only allowed way to authenticate a user is to use the Windows AD.

[Kurt_Bremser]

Define "when needed"? Who determines that, and when, and what are the criteria?

[Criptic]

The user does this at his own discretion. I know this sounds bananas but I'm not the one who decides on these measures.

[Kurt_Bremser · Accepted solution]

Then the user just has to run a single libname statement. Problem solved. If necessary, provide them with a centralized include, so you can change the physical pathname from a single file.

[Criptic]

I thought about that but I was wondering if there was a more elegant solution.

[Kurt_Bremser]

If this could be packed into a standard project (that is loaded automatically when EG starts), you can define an autoexec process flow in that project, containing the libname code and execute the libname depending on a user prompt.

[Criptic]

Thank you this is a great idea. But I think the perfect elegant solution I'm looking for doesn't exist. So I'm probably going with the lib statement as that seems to be the least intrusive for the users and our system

[Kurt_Bremser]

An elegant solution always includes some kind of automation. "The whim of a user" is hard to automate.

[ronan]

Ok, I see, thanks for clarifying. You are trying to declare some hidden libraries based on Windows shared folders for specific users. As @Kurt_Bremser mentioned, its quite difficult to declare something *and* to keep it undeclared : you have to choose either way, not both in our coarse euclidean universe ! (at smaller scale, someone has told some time ago, things might different 😉 )

For this kind of purpose, you can of course let the user assign manually the library in her/his session as shown above.

You can also use indirect libraries assignments based on System environment variable, here Windows folder paths (I assume) :

http://documentation.sas.com/?cdcId=pgmsascdc&cdcVersion=9.4_3.2&docsetId=hostwin&docsetTarget=n07bu...

Assuming you declare at the OS session level some "LSENS" (name it as you like following SAS libname namings rules) environment variable like

LSENS=Z:\SENSITIVE_DIRECTORY_PATH

then, in the SAS session, your SAS user can access any SAS tables stored in this directory without any prior explicit libname assignment. 

Running a sas code like this one will automatically assign LSENS libref the first time it is encountered :

data LSENS.mytable;
set source_table;
run;

[Kurt_Bremser]

How many users are we talking about, and how often do they change from one group to another?

[Criptic]

About a dozen users. This extra lib contains sensitive information which the users are not to use in their daily work so we want to exclude it from their "normal" Profile for auditing reasons