It’s a plain vanilla SDL Tridion install where users are added in the CMS CME.
If user successfully log-in to the SDL Tridion CME (No LDAP-AD sync is used means MMC console has no LDAP-AD stuff).
Now user goes on doing his/her business edit/create of content page or navigation stuff around in CME.
Does Tridion authenticate every time user does such activity? Is this authentication done against the LDAP-AD or some sort of cache (if there is one?)
Long long time back someone from advised me there is a config in Tridion where you can turn it On or OFF to authenticate for each/every activity user does after successful login.... (am not able to recall the clarity of the conversation).
I believe IIS will indeed re-authenticate every request.
If you use something like Fiddler (which I strongly recommend) you will see that every request to a URL comes back first as an HTTP 401, then is sent back to the server with the correct credentials.
So, yes, every request must be authenticated. If you disable a user account while that user is working in Tridion, he will start getting "access denied" errors half way through their session.
Yes - Tridion will authenticate you every time. In other words, every time you make a web request, a new TDSE or Session will be created. This can be far more often than you might think. I don't know the details for SDL Tridion 2011, but back in the R5 days, I recall that it took 6 authentications to load your starting view of the GUI.
It's quite likely that authentications against an LDAP server might be cached. The old ISAPI filter did this, however I don't recall the authorization lookups being cached. There was never a solid requirement to support exotic or "heavy" LDAP integrations.
There used to be a setting that would make the GUI cache the TDSE, but this was only ever an internal-use experimental feature. I wouldn't recommend trying to use it, and it's very clear that this configuration isn't supported.
Related
Before I start here: this is a duplicate from another post at serverFault.com ("https://serverfault.com/questions/1009946/hcl-domino-how-to-drop-users-logged-in-with-ltpatoken"); I first felt that would be the place to ask, but since I never got an answer I decided to try once more here.
We are running a Domino server (V 10.0.1 FP3) hosting a number of Xpages applications. Apart from the admins all users are accessing those application through http only (i.e., no nrpc / Notes client access).
The users' person data are synched from AD to Domino via TDI. Authentication is done against the company's AD, this is configured through a Web SSO config document. There however is no complete SSO set up so that users will have to authenticate when first accessing the applications through their browsers.
For application related reasons we set the Ltpa token's expiration time to a rather high value (if necessary I am willing to discuss the reasons for that in a separate thread, but this is not really related to this question here).
Here's a screenshot of the config page:
Domino's http task is restarted every morning at 2:30 through a program document issueing
restart task http
Some observations from that server:
an http restart apparently doesn't invalidate the tokens, i.e. once the http is back up a user who kept the browser open can easily continue accessing the applications without having to re-authenticate (within the expiration time frame). (EDIT): This appears to be true even if the entire domino server is restarted
if users simply close their browsers instead of correctly logging off the tokens at the server side aren't removed (again, as long as they don't expire). If then the user logs on again a 2nd /3rd / 4th token for this user appears server-side
there's apparently no direct way to drop a user session, neither through a simple drop console command nor through admin client actions
Question:
are there ways to drop those user sessions from the server side and/or truly invalidate the tokens?
Basically, what I'm looking for is a way to make sure that users have to re-authenticate every morning. As http is restarted at 2:30 every morning (see above) it would be ideal to also do this at or around that time.
For completeness:
for this server we use an Internet site document which is setup like this:
Any hint is very welcome.
I have been puzzling over this and can't think of an good way of doing this. I am developing a website that would require the user to log in to use the system. I'm thinking of using ASP.NET MVC 4's built in authentication. That isn't much of a problem.
The user would be able to use tools on another server (our server would authenticate him and tell the other website, he is good to go, these messages are passed via HTTPS using XML). The other server, require us to create an authentication token for the user to use when the messages are passed between us.
We need to keep the token in our database to authenticate for every request/response with the other server. Which means that this "token table" knows nothing about the forms authentication time out on our server and vice-verse.
Now the problem, let's say the user uses the other server's tools. He would be on the other server for a long time, this would cause the authentication on our server to log him out, since there doesn't seem to be any perceived activity. The other server will not log him out since we are manually maintaining the token. This would be a troublesome for the user, because now, if he needs to use our service, he'll have to log in again even though he was "online" all the time.
Is there a way to "sync" the 2 authentications? At first I was thinking of getting our server to look up the "token table" (instead of using the built in authentication) so that if the last activity was x ago, the user will be required to log in again, this would solve the untimely logging out from our server. But I'm worried about the security implications.
What would be the best way to do this?
Thank you.
Desmond
If I've understood you correctly you are using Forms Authentication in an MVC4 application to authenticate users, but users will also use another web service located on a different server and so while they are using this other server you don't want the MVC4 application's authentication (for the user) to timeout. Is that correct?
If so, one idea that comes to mind is that your MVC4 application could have an API to the external world that would take in a username and use RenewTicketIfOld() to refresh the timer associated with the ticket. You could do this via the other web server making an HTTP request or by simply placing some AJAX on the page to call the API on every page.
There are, of course, security concerns with this method that you would need to consider. Without knowing more about your situation I'm not sure what solution would be best.
We have a requirement to enable drag and drop of content from Alfresco to a PLM application. Now we have created a new custom view with the PLM product and have incorporated an SWT browser in that view. The idea is that the user would enter the alfresco url and he would be able to drag and drop contents from Alfresco to PLM product using this new view.
The trouble here is that we are being asked to develop it as a single sign on application. The moment the URL is entered by the user, alfresco would ask the user his login credentials.
The user authenticates himself and would be able to view different documents.
But in order to actually download them, we need to set the user info. specifically the user name and password in the request to Alfresco. This is where we got stuck.
Is it possible to get a session or an equivalent identifier codefully [ Note that user visited alfresco url and has authenticated himself. So, we dont have any hold of his information there. ].
Requesting you to share any ideas...
Thanks,
Pavan.
Note: A new UI that would prompt the user to enter user name and password might be possible. But we do not want to resort to that approach.
First, some background.
Most web SSO systems work by authenticating the user themselves, and then setting a custom HTTP header containing the user identify (normally a plain username) which is sent to your web applications by a proxy. I'm not sure if that would work for you, but you may wish to investigate integrating CAS with Alfresco, assuming that both your applications are webapps.
Other options for SSO with Alfresco which might work for non-webapps are NTLM (old and insecure) and Kerberos (much more secure; recommended). These normally integrate with your operating system login session but must be configured in the user's web browser as well as in all the applications that you wish to SSO enable.
In summary, there are a few options that may be available but it depends on the nature of the second application that you want to integrate Alfresco with. I would suggest that you do some further technical investigation based on these areas and any others which others might suggest, and then come back with any specific questions that you have.
I have an asp .net webforms app that uses forms authentication. For a small number of users we have a problem where they log in, they navigate to a couple of pages and then they are asked to log in again. Once logged in for a second time they seem to be able to stay logged in as expected. They shouldn't be asked to login the second time.
This is a single server, no web farms, nothing tricky.
This only happens to a few users, but it does seem to be all users from the same building. I am unable to replicate this and at this point might even start to deny that t was happening if one of our trainers hadn't watched it happen to a couple of customers.
Has anyone else seen anything like this?
I am also seeing a lot of "Membership credential verification failed." errors in the event log. This may be related, but all the googling I've done seems to point to web farms and the like, not a single server.
UPDATE
There is no proxy server, the IIS server and the browser (IE8) are both on the same machine.
The AV software installed is Symantec Endpoint, on one machine, on the other the user didn't have any AV at all (AV Fail!).
The browser is IE 8 with no frills, not a single addin that didn't come with the default installation.
Both session and user login time-outs are set to 30 mins and the problem happens within 1 min of the user logging on.
Logging shows the user to only have one IP address.
I have tried the sessionMode in all it's variations, this doesn't seem to make any difference.
Something has to be causing ASP.NET to think these users have new sessions or their authentication cookie is getting invalidated. Here a a few things I can think to check:
Are the users accessing the site through a proxy server? One of our customers has a proxy that will sometimes close all open connections causing ASP.NET to see the session as new.
Could an overly agressive anti-virus, anti-spyware product be "eating" the session authentication cookie?
Do they have a cookie manager browser add-in that is causing the authentication cookie to disappear or change?
Sounds basic but I've seen this happen because of site timeouts being set too short. If the user sits on the page for longer than the timeout, they will be forced to logon again. And this could be specific to a page when that page presents a large amount of data that takes a while for them to go through.
One other thing I just thought of, have you allowed multiple worker processes for the ASP.NET process (aka web gardens)? If so, the same constraints as with a web farm would apply for authentication.
Crack open Fiddler from the problem user's PC and see what's getting passed in the headers. My bet is on a proxy server and or networking issue.
Are the users possibly coming from a dynamic ip address? I've seen problems where the users sessions get messed up because the IP address that they're accessing the site from changes for some reason.
Are the people this is happening using a browser that's somehow different (different browser, different version, different extensions)? That could be a clue.
In general, when the problem is somewhat reproducible or at least predictable, I use Http Fiddler. Install it on a client machine, turn it on, and start browsing (this works via a system proxy - so it'll work for firefox, IE and any other proxy-supporting browsers alike). Fiddler will record all http traffic between client and server, and you can then peruse such a session later on to find any oddities.
It's a long shot, but one thing I've seen happen occasionally that can lead to these sorts of unpredictable errors is scripting parallelization issues: sometimes buttons + links have onclick handlers which cause a post-back. If you have several such handlers that fire on the same event - in particular when the default event still fires additionally to your custom onclick or whatnot - you may be causing several postbacks when it appears to be just a single postback. That can cause all kinds of unpredictable weirdness as it's not entirely clear which request ends up "winning" - and some odd errors may cause a session to terminate. Since this behaviour is very browser + network latency sensitive, it seems quite unpredictable when it occurs.
Delete the cookie on the client PC's that are playing up
ASP.NET Forms Authentication can redirect users to the login page if they do not have the credentials to access a specific page. It does this so that users who may have more than one login are given the opportunity to login with another account which may have the appropriate access. Basic question I know, but are the users using the same credentials the second time they log in?
Its possible that you have don't have specifically specified asp.net to use cookie based session but are allowing either cookie or cookieless sessions.
In the later case the session id is embedded in the Url. The type of issues you are experiences might be explained by that. Basically depending on how you define your links, some of them would not get the session id, so the user would get a new session when using those links - or maybe during a redirect. That could explain why at specific parts of your site the users loose their session.
If you have the mixed mode enabled, try setting it to only cookieless and go through your site.
Update: Based on the extra info posted there is surely more info needed for it. Some extra things to check:
Are you using subdomains, if that's the case the cookie might not be configured to allow that and that doesn't fail in all environments.
If you are using in-process session, make sure there isn't a bug in the application causing it to restart the process
Maybe what's causing it to ask for login again is an authorization check, and you have an issue on some roles related code
Is it possible that the user is just opening a separate window? ;)
To rule out the possibility of the browser or a browser addon messing things up, have you checked their User Agent strings? If they are randomly distributed it might not cause the problem, but if they're all the same, this might be a hint too.
I have a Drupal site with user logins. Embedded within this site is a Flash application that shows some data to everybody but allows extra functionality if the user is logged on. From within Flash, I'm using XMLRPC to access the system.check method (to determine whether the user is logged in) and the user.login method (to log in a user from within Flash).
Within Flash, everything works fine. However the Flash login state does not seem to correspond to the rest of the site. For example, if I invoke user.login via XMLRPC, subsequent calls to system.check show that I am logged in, but the Drupal user page still says I'm logged out. Or if I am logged in both places and then I log out via the Drupal user page, the next call to system.check still indicates that I am logged in.
How can I make the login state consistent between the Drupal GUI and my embedded Flash app?
(Note: I am not using any XMLRPC library, I am just constructing the requisite XML manually and sending POST methods using a URLRequest object.)
EDIT: I have confirmed via this question and also via testing with a Web Proxy that the SESS cookie returned by the user login page is being picked up and sent back by the flash application.
EDIT: And now I have shown experimentally that even though Flash (via Safari) is sending the same cookie, it gets back a DIFFERENT cookie when it connects to the XMLRPC service than when it requests and HTML page. In other words, Drupal just doesn't support this kind of synchronization and I'm stuck. I'm accepting the answer below that put me on the right track.
EDIT: AMHPHP is not fully released for Drupal6 as of this writing, but it turned out to be installed on the site anyway. Using the DrupalSite library, I was very easily able to log into and out of the site from flash, and the login remained consistent between flash and HTML.
I'm not terribly familar with Flash, but do the URLRequest objects "inherit" state from the browser session, including the user login cookies? If not, you'll need to explicitly send the login cookie with your hand-built request or Drupal will think that it's just coming from another web browser at the same IP address.
If you're not quite sure, using the Firebug plugin might be useful. It lets you inspect any requests that are being piped through the browser, examine their headers, and look at the raw HTTP response object that comes back.
Update: Even more important than the flash widget getting a session cookie is the flash widget getting the SAME session cookie as the web browser itself. Drupal allows users to log in from multiple machines simultaneously, so if the browser is creating one session and the flash widget is creating another, you'd see the behavior you're describing...
It can't be done.
(For details, please see my final edit to the original question and the equivalent information in my comment to #Eaton.)