When i look in a SAS log, there are 4 different Variables to grab User:
_METAPERSON
_METAUSER
_SECUREUSERNAME
_USERNAME
When i check the log, all 4 variables have the same value when i execute the process. So i builded a process which checked _Metauser for some specific user, so that only the users i wanted could do something.
But a colleague of me had the problem that in the variable was not the username stored for him when he called the process, but username#Context. In the other 3 variables, there was only username stored for him, so maybe i can change to one of them. I can not use Metauser, because for some persons there could be an #Context after username.
No i have the problem, which variable to use? What is the difference between the 4 variables? Which to use, to be sure that i only (and always) get the pure username, no matter from where and which programm/Version the User is calling the process?
At the moment i use Sas 9.3 and run the process via webservice
I switched to SECUREUSERNAME for now, but i am not sure if this can make problems for other users, at the moment only 3 work with this process, but there will be a lot more soon
Our authorization concept is based on metadata, so i think maybe i should use _Metaperson...
The _SECUREUSERNAME macro variable is created when the application server executes a Stored Process. The value of _SECUREUSERNAME contains the client identity and this value will be written into the _USERNAME macro variable if _USERNAME doesn't already contain a value.
Under most circumstances, the value of _SECUREUSERNAME will be the same as _USERNAME
_USERNAME Specifies the value for the user name obtained from Web client authentication.
_METAPERSON Specifies the Person metadata name that is associated with the _METAUSER login variable. The value of this variable can be UNKNOWN. This variable cannot be modified by the client.
_METAUSER Specifies the login username that is used to connect to the metadata server. This variable cannot be modified by the client.
There is no easy answer to your question, because it depends on your set up. Do your users have to login by using Metaserver? Is your code always accessed using the WebService? User IDs, what are they, are they ID from AD? Is Single-Sign-On (SSO) enabled? How are the IDs configured on SAS? Do people use Trusted Users to connect?
Regards,
Vasilij
I am using _METAUSER. Now, our systems are set up with SSO, so the username is always without the "#". I have used it without SSO as well, but then I had to use %scan(&_METAUSER,1,#) to strip away the #context part.
From testing in a Stored Process session, 9.2 (windows) environment with SSO:
OS username (in my case, my windows ID)
_METAUSER (when signing in with OS login, eg with SSO, see #Vasilij Nevlev comment in accepted answer)
_SECUREUSERNAME
SAS username (in metadata)
_METAPERSON - Specifies the person metadata name
that is associated with the
_METAUSER login variable. Not sure how this can be unknown, as SMC won't let you enter a blank value.. (anonymous web user is webanon)
_USERNAME - definitely the username as you can use this along with _password in the URL to bypass the SAS login screen.
Related
I have created one independent email task after session to generate failure details email. I have provided information for user and status fields But when I'm trying to add email body in text field all built in email variables are disabled. It says email variables are allowed only within the context of the session.
Can anyone please help me how can I access the email variables in independent email task. I also need to attach session log file with the email.
Appreciate your help
Thank you
Make a dummy mapping and session, you can use built in email variable in that session.
Dummy mapping can have source and target as flatfile (not necessarily having any data).
you can set the configure the email in your actual session it self. in component- post session success/failure.
Either use post-session on-failure email (recommended) or build the message body within the mapping, store it in a variable and use post-session variable assignment to use it on workflow level for the email task.
We are using WSO2 IS as our enterprise identity platform. One of our tenants must restrict the number of concurrent sessions per user for security reasons.
The expected behaviour is the following: when a user logs in, if he/she already has logged in previously and the session is still valid, the new session must overwrite the previous one, so the login ends ok and he/she gets logged out from the first device/browser. Summing up: the new session always invalidates the old one.
I've been researching sites like this or http://soasecurity.org/ searching for answers, but I couldn't find any.
I think that I need to store the WSO2 IS session id (the one that comes in the commonauthId cookie and gets stored in session cache/persistence store) in the user store, so I can check what's the current user session and log out the user if the cookie id and the store id don't match. But there are two main concerns:
Where do I store the user session id? My main user store is LDAP, but I'd like to avoid one extra attribute there, because it's shared with many other applications and promote changes like this could be difficult for many reasons. Is there any way to put this data into a secondary store?
What's the most appropiate extension point in WSO2 IS to add code for storing the session id in a user store? I've been looking through the authentication framework and found that the method concludeFlow in DefaultAuthenticationRequestHandler class is where new sessions are created when there isn't a previously cached one available. It seems a bit "tricky" to extend that method, but I couldn't find a better solution. Maybe you can customize the authenticator or the user store, but I think that's not a good point of extension inside the authentication flow, because the new sessions are created later, in the request handler.
Thanks in advance.
The WSO2 identity server actually doesn't care about the number of open sessions. IMHO the identity server is not the best enforcement point where to check for the open sessions. Once the user is already logged in, you don't have much control over the framework and the user assertions (or an Oauth token) are returned.
Where do I store the user session id?
If you enable the session persistence, the session information (user session, saml SP sessions, ...) are stored in the database. However - it is intended for internal use. If the user logs out or closes the browser, the records may be still there. There's no information about the user web session.
Just a hint - we've used a VPN proxy (Juniper SA as SP) and WSO2IS as IdP to enforce a unique user session (for a new session the old one is invalidated).
Have fun
Is it possible to use userID and the API to record a user having done an event (i.e. reached a goal) by API?
For example, if I set up my GA installation to record userID for logged in users, but the Goal I want to record is something that happens when the user is offline.
Can I use an API somehow to tell Google "User 001 completed Goal X"?
Or, alternatively, can I pull a unique identifier from a user's cookie, store it on my server side linked to the user id, and fake a js call back to Google once the goal is reached, as if the user were viewing a success page?
You can fetch the client id from the cookie. Google recommends to use their get function:
ga(function(tracker) {
var clientId = tracker.get('clientId');
});
as
developers should not directly access the cookie analytics.js sets as
the cookie format might change without warning.
You can then send an event or virtual url using the measurement protocol and set up a goal based on that url or event (btw. there is nothing "fake" about it, this is exactly the thing the measurement protocol is supposed to cover).
The caveat is that the data will probably end up in a new session, so the original source might get lost (that's an issue if you do advertising).
Another approach, if your users are usually logged in, would be the User-ID feature (despite it's name it does not ID individual users, but it allows to collect user data across devices as long as an unique ID is sent per user from each device. The Id is not exposed in the interface).
You would again use the measurement protocol but this time send along the user id (you still need to send a client id, but it will be overwritten by the user id). If you enable session unification the logged-in visits of the users (and your measurement protocol calls) will be stitched together into a user-level reporting (this required a special data view which will include only data from visits that have a User Id set). Unlike the client id, which is generated by the Google Analytics Javascript code, the User ID is generated on your server and passed in to GA.
I am trying to construct a application that will allow a user to reset his domain password and get access to their box while it is off domain and off the corp network. E.G. User is a domain user, is traveling off network and forgets his password. He can of course login using his domain creds because they are cached locally in the HKEY_LOCAL_MACHINE\SECURITY\Cache. Unless of course he has forgotten his password. I have already created a login shell addition that will take the user through web 2.0 style security questions etc. to verify their identity. However the last step, actually updating the local security cache with the new password such that the user can continue to login until they resync with the domain controller eludes me. I have looked through all the API's CredWriteDomainCredentials, CredWrite etc. etc. but there does not seem to be an official way to do this. Does anyone have any idea how to write a new hash to the local store essentially simulating a valid domain logon and cache write event?
I have two web applications different things, but authentication is done only by one (using python and tornado), id like to have the second application access the credential of the user transparently, currently I can read the cookie of a logged in user via the header: Access-Control-Allow-Credentials , so how would i access the cookie, so i can store it (mongodb/redis/anywhere-but-mysql), and retrieve it in the second app?
what I've tried:
self.set_secure_cookie('cookie_name') # works i can see the cookie in subsequent request headers
self.get_secure_cookie("cookie_name") # just after setting the cookie returns None
what I was thinking is to store the encrypted value and compare it later in the second application as and when needed, is this sensible? all that i need to do is to ensure the user is
logged in and they exist in out list of users as of the moment.
So you've managed to set a cookie by one of the servers and then retrieve it on the second? If so, great! That's the trickiest part (imho).
Now there are two ways to go.
Store data in the cookie
Tornado have, as you've noticed, support for secure cookies. This basically mean that you can store data in the cookie and sign it with a secret. If both you servers have the same secret they can verify that the cookie data is not altered and you have successfully distributed data between the two servers. This decentralised alternative is not suitable if you need to store much data in the session.
A shared DB (or an API that the other server can use)
If you go with this solution you just have to store a session key in the cookie. No need to use secure cookie since it's no data stored there. You simply generate a SSID, e.g. ssid = uuid.uuid4().hex, store that in a cookie called something like ssid and also add a record to the DB along with all session data you want to store. I really like Redis for this since you can set the expire on creation and don't have to worry about that anymore, it's pretty fast and the best thing is that there's a nice and easy async lib you can use that plays nice with tornado.