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.
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 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 have been working on IBM Maximo Anywhere apps such as Work Approval and Work Execution for sometime now have few queries regarding the login mechanism used by these apps. To be specific as per my understanding anyone having access to maximo on that particular environment can login into the anywhere apps - is that a correct statement? and if yes then how does it work in a disconnected state? If for any reason maximo is down will it mean that the app will not be able to authenticate a user and hence unable to login as well? And alongwith that is there any other kind of authentication done for example LDAP etc? Are there any different kinds of login failure messages that are displayed depending on why the app isnt able to let the user login? or is it a common one saying "Login Failed"
The first time the user ever logs into the application, they do have to have a connection to the Maximo server to authenticate. We also validate that the user is authorized to use this particular mobile app. We have a security group for each mobile app that the user must be a member of. After the authentication and authorization finishes, we download, store, and sign the locally stored data with the username/password combination, so that on subsequent login attempts, if the server is down, we can fail over to the locally stored data. This also guarantees that the locally stored data is protected.
We support all of the types of authentication configuration that base Maximo supports.
More information here:
http://www-01.ibm.com/support/knowledgecenter/SSPJLC_7.5.0/com.ibm.si.mpl.doc_7.5.0/security/c_authentication.html
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.
I'm getting this exception when trying to access a JAX-WS webservice running on the same WAS 7.0 server as the client.
Caused by: javax.xml.ws.WebServiceException: java.io.IOException: Unable to deserialize the Subjects in this Context, cause: the realms do not match
I have a realm set up for user authentication and this call works fine with that realm disabled. Both server and client are running in the same cell.
My current thinking is that my web service is not providing any realm information at all, causing this problem, so I need to do something in my web service to provide a realm - but what? Even google-fu is failing me on this one!
The Realm is set in the LTPA token assigned to the call, and the realms of the client and server needs to match.
I.e. if client authenticates the user and sets and LTPA token with realm="Ldap1:389" then the server needs to have the same realm set. Or it needs to explicitly trust the given realm. This can be set up in WAS admin console, for an explanation of LTPA have a look here:
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.express.doc/info/exp/ae/csec_ltpa.html
It turned out to be that there needed to be a trust relationship between my local file-based admin realm and the realm I set up for my users to log on with.
WAS seems to do a lot of security gubbins under the covers, but turning on trace output for WSSecurity stuff helps shed light on problems.