When pushing a website update to Azure does the app pool reset? What effects does this have to a user that is signed into the site? Would the user get signed out?
When pushing a website update to Azure does the app pool reset?
Yes. You can check this in the Kudu Debug Console, under Process Explorer. Note how the PID of your application changes.
What effects does this have to a user that is signed into the site? Would the user get signed out?
Signing in with Azure AD (i'm assuming since you don't mention an IdP) is heavily dependant on your token cache strategy:
Assuming you're only using a memory cache for ADAL/MSAL and your app pool restarts —
In this case, the STS and ASP.NET cookie are still in the browser session, your code needs to check the cache and if it looks like a fresh cache, redirect user to STS (Challenge() in ASP.NET). This will be seamless and won't require typing in credentials since the STS cookie was never gone.
If the user session state is also stored in memory (the default for ASP.NET), then you'll lose the user's session state as well (if that holds a shopping cart, you have bigger problems to worry about).
The sensible thing to do is to move to a persistent token cache and a persistent user session store as well. Redis cache is a good choice. SQL is fine too, probably a bit much.
Related
I am using Azure Mobile Apps with deployment slots, with the service provider for login being Microsoft. I have some odd behaviour, during swapping and the users relogin.
Is the performance better/different for AD? [read that it was not for GA yet?]
I am developing in a developer slot with everything specifically configured for this environment, the test and updates are working. I upload the server to staging, now utilizing the same db and settings (except microsoft authentication). The server is again verified to be working both on client and server.
I then use swap to change the staging and production slots. The production slot has the microsoft account login settings.
Upon swap the login by users are continuing indefinitely (no timeout, i.e. several minutes running without any stop) if, the referesh token call is made, as per this link:
//retrieve user info
user = new MobileServiceUser(credential.UserName);
credential.RetrievePassword();
//refresh token
user.MobileServiceAuthenticationToken = credential.Password;
JObject refreshJson = (JObject)await ((App)Application.Current).MobileService.InvokeApiAsync(
"/.auth/refresh",
System.Net.Http.HttpMethod.Get,
null);
My initial question is therefore is it possible to insert a timeout e.g. 2 seconds on the call to force the user to re-enter their credentials?
Because it seems to work if the user logs out and then back in with normal login procedure:
user = await ((App)Application.Current).MobileService.LoginAsync(provider);
credential = new PasswordCredential(provider.ToString(), user.UserId, user.MobileServiceAuthenticationToken);
vault.Add(credential);
string newToken = refreshJson["authenticationToken"].Value<string>();
Question(s)
Is it possible to insert timeout on MobileServiceClient.invokeApiAsync calls?
Is there some setting that can be set so the swap mechanism does not introduce this issue?
Is there a way to improve the login/relogin flow, the users are complaining that the login is failing often. I cannot replicate it in other instances than during the swap. Can this be because of distance to the server?
Therefore would Traffic Manager be a solution? However, I cannot see how it should be enabled if I am using microsoft login. Since a service is bound to an application name for authentication. How should the Traffic Manager be used in this respect?
Is there some setting that can be set so the swap mechanism does not introduce this issue?
Not sure if this applies to your case, but there is a known issue where certain app settings can actually cause issues with swapping. Do you have any app settings defined that end with _EXTENSION_VERSION or that start with WEBSITE_AUTH_? If so, try removing them and see if that resolves the issues you're seeing.
Is there a way to improve the login/relogin flow, the users are complaining that the login is failing often. I cannot replicate it in other instances than during the swap. Can this be because of distance to the server?
I've never head of an issue like this. Anymore details on the failure you can provide, such as a status code? One thing you can do is enable Application Logging and you should be able to get detailed information about the refresh failures.
Therefore would Traffic Manager be a solution? However, I cannot see how it should be enabled if I am using microsoft login. Since a service is bound to an application name for authentication. How should the Traffic Manager be used in this respect?
I think the way to make this work is to use a single Microsoft account application for all mobile app backends that are being load-balanced by traffic manager. The redirect URL that gets configured needs to use the common host name that is registered with Traffic Manager.
Is it possible to insert timeout on MobileServiceClient.invokeApiAsync calls?
From the API, It seems we can not set timeout in this method, refer to https://msdn.microsoft.com/en-us/library/azure/mt691682%28v=azure.10%29.aspx?f=255&MSPPError=-2147217396 for more details.
I have one Node Bluemix application configured with the SSO Service & connected with a Cloud Directory. I can successfully authenticate the user but I'm having problems to accomplish a successful logout. I have tried req.session.destroy, req.logout, and express-passport-logout module to end the session. But none of them worked. I also tried to remove cookies from my application but it didn't work as well. The only way it is working is by restarting the browser or clearing cookies from browser. Does anybody know how to achieve a SSO logout from the application?
The last time I used the service this was not possible. The problem is: what you are doing with the listed commands is to close your application session, not the one on SSO service. So when the user comes back (with the same cookie) your application will ask SSO service to check and it will accept the user (since the session there is still open). Currently there is no API available to close the session on the SSO service instance.
Actually, this becomes more complex when you use external IdP: even if you close the session at the SSO server, the browser will still have a session with the real IdP the user logged in from, which depending on the configuration of your service instance could be one or more of IBM, Facebook, Google, Linkedin. Some of these IdP's provide long-lived sessions via persistent cookies and your application can't force the termination on their side. That means that on next click of the "login" button, particularly in the case where the SSO service instance is configured to use only one IdP, SSO will happen seamlessly with no further interaction.
Take a look here to get more information.
As Umberto says, maybe it was not possible before, but now it seems to be:
Check this. You can redirect your user to this:
/idaas/mtfim/sps/idaas/logout
At least this seems to work if you only use Cloud Directory.
I've been reading for the last hour but it's still not clear for me how to automatically authenticate the current windows user in my node js application.
On my office PC, I'm already authenticated with my AD user when I access our company portal in Chrome (as it was added as a trusted sites). So the main question for me is what do I have to do to automatically detect/authenticate the user in my nodejs app if I add my site to the trusted sites? I'm pretty sure the browser must do half of the job as it probably sends some kind of data (hash) in the request, based on which the application must authenticate the user. I suspect this is the "www-authenticate: negotiate" header as I noticed this sends a hash in the request when I access the portal.
So far, the only tracks I'm still investigating are:
https://gist.github.com/charlesdaniel/1686663
But it's still not very clear for me how this automatic authentication works and what are the leads I should follow next. The entire process is still unclear to me
I appreciate any advices on this or at least a mid-level explanation on what happens behind the scenes when I access a page in Chrome and it automatically authenticates me. Thanks
I wanted to implement a certain architecture that decouples my rest API from a web server that would be used as an agnostic template engine such as DustJS. My back end rest API would be built using service stack.
The main thing that I like about service stack and NodeJS is that they both provide a way to authenticate but I only need a central way to access credentials for granting access to API calls as well as restricting certain content on my views.
The application I want to develop is a subscription based dating website, so that presents me with a few problems. The parameters involved are roles, groups, authenticate and authorize. It's easy to implement on service stack but I am confused with mainly how the front end could get access to that information.
How would I implement a scenario where the front end retrieves credentials once and does not have to keep making API calls to check the DB or Cache to see if it checks out? Do I need to implement a different method in handling clients who wish to remain logged in, or does that typically get solved just by setting a time stamp value?
Thanks for your time everyone.
Sessions are just AuthUserSession POCO's stored in a Cache
The way Authentication works in ServiceStack (and most web frameworks) is that when a User successfully Authenticates, an Authenticated UserSession is created for that User and stored in the registered Caching Provider you've registered in ServiceStack's AppHost. The session id for that the Authenticated UserSession (aka AuthUserSession) is then stored in the Users cookies under the ss-id Temporary and ss-pid Permanent cookies.
Session Cookies re-sent on each request
Cookies by design are re-sent on every subsequent request to that domain which is how Server frameworks know which Authenticated User is making each Request by simply retrieving the AuthUserSession from the Caching provider stored under the following key:
urn:iauthsession:{sessionId}
Where {sessionId} is either the Temporary (ss-id) or Permanent (ss-pid) cookie depending on whether the User Authenticated with ?RememberMe=true or not. This also means your node servers can also easily access a Users Session authenticated with ServiceStack by accessing the same cache with the above key format.
Most caching providers are distributed
All Caching providers except for the MemoryCacheClient (default) are distributed which means that each of your load balanced App Servers will naturally be able to tell if the User is Authenticated or not.
Accessing User Sessions is very cheap
I wouldn't be concerned with performance for retrieving the UserSession since accessing a User Session only takes a single cache hit to access the blobbed Users Session at a single key - which is closest to the cheapest network request your Server can do.
Can avoid network requests with a Write-thru Cache
One way you can avoid the single cache request to retrieve a Users Session is with a write-thru cache where when a User is authenticated it is saved in both a local MemoryCacheClient as well as a distributed ICacheClient (e.g. Redis) that way when the request for a Users session is requested it first looks at the local cache and if it doesn't exist will call the distributed cache to fetch it, storing it in the local cache before returning it. The one thing you need to watch out for is to synchronize any changes to the distributed cache with the local caches stored in the memory of all the load-balanced App Servers which you can use something like Redis Pub/Sub to send messages between all the different App Servers.
You have to check SOMETHING. Your website will presumably establish a cookie with the client, and every time the client accesses, it COULD check in the DB that the cookie is valid, but this is possibly wasteful since the max unique users accessing the site within an hour say is probably very small compared to the total subscription list, say 1% for examples sake. So, you could just have a HASH memory cache that checks the cookie session ID, optionally with the IP address of the client if you like that extra security. So use the session ID and optionally IP to find the data, and make sure you store the last access time in the data so you can invalidate this memory cache entry if it's not been accessed for too long, or so you can garbage collect it, and store any other data that you actually need to actually do whatever else you need to do.
If your website becomes large and scales over many machines in a load balanced cluster you can load balance to servers based on client IP, which means this cache will not become unnecessarily large since usually a given client will go to the same server, but if they switch it's fine as your web app can just fall back to loading from the database.
Judging from all I understand JWTs would be solving your problem. Since a JWT-token is not opaque you can do any kinds of validations from it's payload locally, without checking a central session service.
It's not too straightforward, but speaking simplified: "It solved all our problems with sessions"
Auth0 provides a lot of good reads on it. Start here.
we have deployed a OpenAM V10 cluster with two nodes and sometimes and several SPs configured. When a user logs into the system, the systems validates its credentials and starts the user session but sometimes it seems to "cross" the session with one from another user whom is already logged into the system. After that, when the user tries to access any of the registered SPs an error is shown and it's forced to be logged again. So, in fact, it's not really a security problem but it's not cool at all.
We really don't know if the problem is in OpenAM or in the load-balancer.
Any idea is welcome.
OpenAM does not use HTTP session but it's own session id which is cryptograhically secure, so it's very unlikely there is a SSO session ID clash.
It's not clear what "cross the session" really means ... a session in you app? Then it's an application issue, not an OpenAM issue.
It will never be an LB issue.