Do the session management between openAM and protected application work's in CDSSO environment. Because I find that in CDSSO setup if I invalidate a session in openam side, it still remain active in application side.
You either have to ensure that notification mode for the agent, protecting the app works, or use polling mode for the agent, but minimal polling mode is 1 minute. So users can access protected pages for another minute after you invalidated the session on OpenAM.
Also be aware what polling means which regard to number of requests to OpenAM infrastructure.
Related
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.
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.
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.
I have installed OpenAM in domain 1, and my application is in domain 2 protected with J2EE agent,My question is, Once I get access to my application after authentication do the agent contacts over the network to openam(for authorization), for every click I make on my application,If the answer is yes than what will be the performance impact if my agent and openam is in two domains which are geographically separated, If the answer is no,how does an agent invalidates an access to my application,when admin invalidates a user session from openAm home page.
The agent needs to communicate with OpenAM for authorization decisions, but it will cache the resulting decision so subsequent evaluations will be local.
OpenAM can call back the agent in the container (that is what agentapp.war is for). This can be used to notify the agent that the users session is no longer valid. For example, if they logged out of OpenAM, or their session expired.
The performance impact will be very small. OpenAM is supporting installations with tens of millions of users - so unless your site is very large this will not be an issue.
You generally want to localize the agent to OpenAM traffic to the same data center when possible. If you had multiple regions you would want to have OpenAM instances in those regions. They can be configured to fail over to each other if required.
By default OpenAM and J2EE Policy Agent communicates in Notification mode so OpenAM would notify (check notificationUrl field in config properties) an agent for any Logout events. Now, as mentioned by #warren-strange a J2EE Policy Agent periodically sends request to OpenAM server and that way it would be able to know if Token exists and is valid.